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ABSTRACT 


In light of the continued investment in information 
technology by businesses in hopes of achieving a measurable 
benefit in terms of process efficiency and effectiveness, 
business process reengineering (BPR) is becoming 
increasingly important. BPR suggests that by radically 
redesigning underlying business processes, companies can 
achieve breakthrough improvements in productivity. BPR, 
however, is a knowledge intensive endeavor. A decision 
support tool called KOPeR-lite was developed with the 
intent of encoding the knowledge held by BPR experts and 
documented in BPR literature. This tool promises to assist 
BPR novices who are tasked with reengineering inefficient 
or ineffective processes. The purpose of this thesis is to 
determine the viability of using KOPeR-lite when BPR 
novices undertake process reengineering projects. It also 
proposes reengineering solutions for the permanent change 
of station orders process for USMC officers, which will be 
presented to the leadership in the Headquarter, U.S. Marine 
Corps (HQMC) Manpower and Reserve Affairs (M&RA) branch. 
If adopted, one of the proposed solutions promises to 
dramatically improve process performance. 
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INTRODUCTION 


I. 


A. BACKGROUND 

We often hear the phrase, "work smarter, not harder." 
However, when working outside our personal areas of 
expertise, this often can become a challenge because we 
lack the resources, knowledge, or human resources to aide 
us. By developing and using expert systems, we can attempt 
to mitigate this problem. 

Expert systems are computerized, advisory programs 
that attempt to imitate the reasoning processes and 
knowledge of experts in solving specific problems. The 
developers of expert systems attempt to capture the 
knowledge held by human experts by distilling their thought 
processes and analytical techniques into a series of rules 
or heuristics applicable within a specified domain. These 
rules and heuristics are then codified in a form that a 
computer can use to analyze a problem. Once the expert 
system is developed, a user can input information 
pertaining to a problem within the domain for which the 
expert system was designed. The system then will generate 
proposed solutions based on its rule/heuristic knowledge 
base. 

Though a situation or process may be novel to us and 
we may be content to maintain the status quo, experts may 
have analyzed a similar situation and developed a more 
effective process. Why not tap into this expertise and 
take a closer look at the processes we're involved in on a 
daily basis? We thus ask, "Is there a better way of doing 
this?" Expert systems may well help us answer this question 
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more effectively than could a novice working alone, and it 
is hypothesized that these solutions may be equal in number 
and viability (if not better) and will be generated in less 
time than it would take a novice working alone. 

B. OBJECTIVES 

The purpose of this thesis is to determine the 
viability of using automated tools, such as KOPeR-lite, 
when undertaking process reengineering projects. It also 
proposes reengineering solutions for the USMC Personnel 
Assignment Process, which will be presented to the 
leadership in the Headquarter, U.S. Marine Corps (HQMC) 
Manpower and Reserve Affairs (M&RA) branch. One of the 
proposed solutions may dramatically improve process 
performance. 

C. RESEARCH QUESTIONS 

The central theme of this thesis is process 
reengineering, in particular the efficiency gains, process 
flow improvements and decreased redundancy, that may be 
realized through automation and other enablers of dramatic 
change. Currently, the process of developing reengineering 
solutions is largely done using manual techniques that 
demand extensive knowledge and expertise. To this end, the 
primary research question is: How can automated tools such 
as KOPeR-Lite enable reengineering novices to develop good, 
viable reengineering solutions? Secondary questions 
include: 
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What is reengineering, and what computer based 
tools are currently available for process- 
redesign automation and support? 

How does KOPeR-lite function, and what evidence 
exists concerning its redesign effectiveness? 

Which important U.S. Marine Corps processes offer 
good potential for reengineering? 

How can KOPeR-lite be employed to redesign 
important processes in the U.S. Marine Corps? 

How can the results of this study be generalized 
to other organizations and processes? 


D. SCOPE OF THESIS 

The scope includes review of materials on knowledge- 

based systems, decision support systems, and process 
reengineering. An analysis of experimental data are then 
performed to assess the effectiveness of KOPeR-lite. 
Finally, it draws from the results of this analysis to 

apply these and other applicable techniques in 
reengineering the processed followed in making USMC 
Personnel Assignment decisions. 

E. RESEARCH METHODOLOGY 

The methodology used in this thesis research consists 
of reviewing data from: 

• Existing material (i.e. books, professional 
journals, the web, etc); 

• Data generated by students tasked with 

reengineering software engineering processes; and 

• Information from HQMC and 1st Force Service 

Support Group (FSSG) on the existing process for 
personnel assignments, to include: Marine Corps 
directives pertaining to the personnel assignment 
process as well as information gathered via 
personal interviews. 
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The research method also includes process analysis using 
the Davenport framework and using results from analysis of 
experimental data associated with KOPeR-lite to redesign 
the U.S. Marine Corps Personnel Assignment process. 
Analysis of experimental data is accomplished through the 
method of content analysis, and analyses of at least two 
researchers are integrated for reliability. Reengineering 
is accomplished through a combination of Davenport's five- 
step process: (1) Identifying Processes for Innovation; (2) 
Identifying Change Levers; (3) Developing Change Levers; 
(4) Understanding Existing Processes; and (5) Designing and 
Prototyping New Processes (including use of KOPeR-lite). 

The data obtained are then used to make 
recommendations to usefulness of KOPeR-lite in process 
reengineering and propose a reengineered solution to the 
current personnel assignment process. 

In order to analyze and develop a reengineering 
solution to the current U.S. Marine Corps Personnel 
Assignment process, data are gathered on the baseline 
process by reviewing pertinent orders and directives which 
outline current processes as well as by interviewing 
manpower personnel at a Major Subordinate Command, 
specifically 1 st Force Service Support Group (FSSG) aboard 
Marine Corps Base Camp Pendleton. Once this is done, 
attributes of the baseline process are delineated and 
employed for KOPeR-lite analysis and process pathology 
identification. Based on KOPeR-lite's proposed 
transformations, one or more redesigns are developed and 
included. Following this, the redesign is provided to the 
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Assistant Chief of Staff, G-l, 1 st FSSG for review and 
comment. 

F. ORGANIZATION 

This thesis is organized as follows. Following this 
introduction. Chapter II provides a brief historical 
outline of process reengineering and why it is pursued. 
Additionally, the Davenport framework is presented along 
with a functional description of KOPeR-lite. KOPeR-lite is 
used to depict processes and gain an understanding for 
redesign. Chapter III covers the experimental design, 
data, analysis, results and implications. Chapter IV 
addresses the matter of reengineering the permanent change 
of station (PCS) orders process for USMC officers. Chapter 
V summarizes the results of research and study as well as 
makes recommendations for process improvement and areas for 
future research. 
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II. PROCESS REENGINEERING 


A. HISTORICAL BASIS 

The assembly line, the cotton gin, the type setting 
machine, and the typewriter: these are all examples of 
concepts or inventions which led to quantum leap 
improvements, such as increased productivity, reduced 
costs, and reduced labor. Each time an invention or new 
concept is developed, underlying processes in the domain in 
which it is to be implemented must be evaluated for radical 
change so that the full potential of the invention or new 
concept may be realized. Business process reengineering 
(BPR) suggests that by radically redesigning their business 
processes, companies can achieve breakthrough improvements 
in productivity. 


B. WHY REENGINEER 

Today, some of 

the 

catalysts 

for 

change 

include 

increased competition. 

both 

domestic 

and 

foreign. 

greater 


availability of information to customers about competing 
products, a shift from manufacturing to service industries, 
and the advent of new technologies. The latter has become 
arguably the biggest driver for change over the past 
decade. Companies both large and small have made large 
capital investments in technology only to realize little if 
any quantifiable improvements in productivity. 

One cannot invest in technology and then simply cross 
one's fingers and hope for the best. A plan must be 
formulated to ensure underlying business processes are 
adapted to make full use of the capabilities afforded by 
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technology. This includes analyzing process workflow, 
removing non-value added steps, reducing process friction, 
reducing the number of independent reviews or burdensome 
oversight functions, increasing information flow (and 
getting the right information to the right people), and 
providing training, among other things. 

Given the ever-increasing pace of change in the 
business environment, the question asked by businesses 
should no longer be "do we need to change?" Rather, 
businesses need to ask "How can we best change, not only to 
maintain relevance in the changing environment, but to 
realize order of magnitude improvement to develop or 
maintain our competitive advantage?" 

C. DAVENPORT FRAMEWORK 

Davenport (Davenport, 1993) advocates a five-step 
process in the conduct of BPR, as depicted in Figure 2-1. 

Identifying Processes for Innovation 


Identifying Change Levers 


Developing Process Visions 


Understanding Existing Processes 


Designing and Prototyping the New Process 


Figure 2-1. 


A High-Level Appproach to Process Innovation 
(From Davenport, 1993, pg 200) 








Before setting a course for change, either incremental or 
radical, a company must first develop a clear understanding 
of its current state of affairs. By following the 
methodology he outlines, an organization will gain a 
thorough understanding of its existing processes, determine 
what needs to be accomplished in order to facilitate 
change, develop redesigns for pathological processes, as 
well as develop a plan for implementing the change. A 
clear understanding of existing processes, identification 
of associated pathologies, and a decision as to whether or 
not change is needed are of critical importance to this 
methodology. 

1. Identifying Processes for Innovation 

For our purposes, a process is defined as any 
collection of activities that yield some output of value. 
This output could be an input to follow-on processes or 
perhaps some good or service. The case study contained in 
Appendix A, for example, shows the baseline software 
development process comprises six fundamental activities: 
sales, requirements development, design, code, test, and 
independent test and evaluation (IV&V). In this particular 
process, each activity follows the one before in a simple 
linear manner (See Figure 2-2 above) . 
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Figure 2-2. Baseline Process Activity Flow for the 
Software Development Case Contained in Appendix A 


Davenport proposes four criteria to aide in selecting 
processes for innovation: 

(1) the process's centrality to the execution of 
the firm's business strategy, 

(2) process health, 

(3) process qualification, and 

(4) manageable project scope. The goal of process 
innovation is order of magnitude improvement in 
the effectiveness or efficiency. 

Unlike incremental change, which is typically a 
continuous evolution, process innovation should be a 
discrete, focused effort. By selecting a process that is 
closely related to the overall business strategy (e.g. the 
software development process for a company that creates 
software solutions for its clients), the effects of the 
change will be felt more profoundly than would likely be 
the case if a non-core process is chosen for a innovation 
initiative. 

With regard to process health, the more pathologies 
exhibited by the selected process, the greater the 
potential gains one may realize by reengineering it. 
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With regard to process qualification, culture of 
political climate must be such that innovation efforts will 
be well received. Also, a committed sponsor of the 
innovation efforts must be present if there is to be any 
hope for success. Last, Davenport advises that the 
project's scope be well defined to provide focus to the 
innovation process. 

2. Identifying Change Levers 

The application of information technology (IT) as a 
change lever is one of Davenport's foci, in part because of 
the increasing incorporation of and reliance on IT tools in 
the day-to-day activities of most businesses. Another 
reason for this focus is that most businesses have failed 
to realize the full potential of their IT investment. 
Other change levers include training, workflow redesign, 
employee empowerment, and changes in organizational design. 
By using a combination of these tools, business may more 
fully realize the benefits afforded by IT. 

3. Developing Process Visions 

"Common sense tells us that a change must be 'seen,' 
its direction somewhat charted, before anything happens." 
(Jick, 1993, pg 75) A vision statement provides a clear 
picture of the end state desired. It provides participants 
a clear sense of what they are working to achieve and helps 
to focus their efforts. Further, "alignment between 
[corporate] strategies and processes is essential to 
radical change in business processes." (Davenport, 1993, 
pg 117) Additionally, "process change without strategy and 


11 



vision seldom goes beyond streamlining, with a resulting 
incremental reduction in time and cost." (Davenport 1993, p 
119) A vision, therefore, is necessary if there is to be 
any hope for achieving the results desired. 

4. Understanding Existing Processes 

Until a clear understanding of the baseline process is 
developed, changes will produce haphazard results. By 
developing a firm understanding the existing process, one 
can more intelligently go about finding solutions for the 
processes' associated pathologies. Davenport articulates 
four reasons why it is important to develop a clear 
understanding of existing processes: (1) understanding 
existing processes facilitates communication among 
participants in the innovation initiative; (2) in most 
complex organizations there is no way to migrate to a new 
process without understanding the current one; (3) 
recognizing problems in an existing process can help ensure 
that they are not repeated in the new process; and (4) an 
understanding of the current process provides a measure of 
the value of the proposed innovation. (Davenport, 1993) 

5. Designing and Prototyping the New Process 

For the activity of designing new processes, Davenport 
states that "the design activity is largely a matter of 
having a group of intelligent, creative people review the 
information collected in earlier phases of the initiative 
and synthesize it into a new process" and that "the success 
or failure of the effort will turn on the particular people 
who are gathered together." (Davenport, 1993, pg 153) 
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In developing new process designs, he advocates using 
brainstorming sessions. The goal of these sessions is 
generating creative alternatives by all participants in a 
non-judgmental atmosphere. Graphic representation of the 
redesigns is recommended as it helps understand process 
flows. 

Following redesign generation, participants must 
assess feasibility, risk, and benefits of the alternatives 
in terms of overall strategy and vision. Prototyping of 
redesigns is "an iterative process in which the fit between 
new process structure, information technology and 
organization is refined and re-refined." (Davenport, 1993, 
p 156) The output of this prototyping activity is the 
selection of a redesign for implementation. 

D. KOPER—LITE 

KOPeR-lite is a web-based version of The Knowledge- 
Based Organizational Process Redesign (KOPeR) tool that was 
originally implemented in a UNIX environment. KOPeR-lite 
is an automated tool created to help BPR novices develop 
process redesign alternatives without the benefit of 
extensive training in BPR or from the brainstorming 
sessions highlighted in Davenport's framework. It does 
this by making recommendations based on its analysis of the 
metrics inputted by the user for each measure listed in 
Table 2-1 below. 
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Measure 

Graph Based Definition 

Process Length 

Number of nodes in longest path 

Process Breadth 

Number of distinct paths 

Process Depth 

Number of process levels 

Process Size 

Number of nodes in process model 

Process Feedback 

Number of cycles in graph 

Parallelism 

Process Size divided by Length 

IT Support 

Number of IT-support attributes 

IT Communication 

Number of IT-communication attributes 

IT Automation 

Number of IT-automation attributes 

Organizational 

Number of unique agent role 

Roles 

attributes 

Process Handoffs 

Number of interrole edges 

Organizations 

Number of unique agent org. 
attributes 

Value Chains 

Number of unique activity Value Chain 
attributes 


Table 2-1. Example Process Measure (From Nissen, 2000) 


Once these metrics have been entered, KOPeR-lite 
carries out its two primary functions: (1) pathology 
diagnosis and (2) transformation matching by referencing 
its knowledge base. This knowledge base is composed of 
three component parts: (1) process pathologies (2) redesign 
transformations and (3) process models. (Nissen, 2000). 
Pathologies are identified by a series of IF-THEN rules 
applied by KOPeR-lite to the user inputted process 
measurements. Based on KOPeR-lite's analysis of the 
metrics, it provides the user with feedback identifying 
process pathologies. These pathologies include those 
listed in Table 2.2 below. 
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Pathology Class 

Sample Instance 

Problematic process 

Sequential process flows 

structure 


Bureaucratic organization 

Job specialization 

Fragmented process flows 

Process friction 

IT infrastructure 

Manual process 

Checking" approach to 

Review-intensive process 

quality 


Centralized authority 

Long decision chains 

Under-utilized human 

Training emphasis 

potential 


Inhibitive leadership 

Directive supervision 

Centralized information 

Central database architecture 

Deficient core competency 

Low IT expertise 


Table 2-2. Pathologies and Pathology Samples (From 


Nissen, 2000) 


KOPeR-lite then carries out its second function: that 
of transformation matching. The transformations it 

proposes are drawn from its transformation knowledge base 
following the application of another series of IF-THEN 
rules. The knowledge base is populated with expertise 
gleaned from BPR literature. Some of the transformations 
KOPeR-lite may propose are listed below and address the 


pathologies listed in Table 2-2. 


Transformation Class 

Sample Instance 

Workflow reconfiguration 

Process delinearization 

Information technology 

Shared database system 

Organizational design 

Case manager 

Human resource 

Team-based compensation 

Information availability 

Informant agents 

Inter-organizational 

Supplier-managed inventory 

alliance 

Management & culture 

Employee stock ownership 


Table 2-3. Taxonomy of Redesign Transformations (From 

Nissen, 2000) 
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E. HOW MIGHT THE MILITARY BENEFIT FROM PROCESS 
REENGINEERING EFFORTS 

There are numerous ways the military could benefit 
from using such a tool. Ask just about anyone in the 
military if they have experienced a process that they felt 
was less than efficient, and you will almost assuredly 
receive a long list of processes that they feel have room 
for improvement. 

Some examples are listed below: 

(1) USMC Personnel Assignment Process. There are 
numerous sources that a major command uses to find out who 
is coming to their command. Unfortunately, there is no one 
single source and the multiple sources have different 
degrees of accuracy. By being able to more effectively 
identify inbound personnel well in advance of their 
arrival, personnel sections would be able to make better 
assignments and offer inbound personnel with better 
assistance during the somewhat hectic permanent change of 
station process. Additionally, receiving commands would be 
able to make better plans based on projected personnel end 
strengths. 

(2) Transition to Smart Card Technologies. There are 
numerous initiatives being pursued with regard to smart 
card technologies. Some of the issues raised are: How will 
we collect information from various sources for personnel, 
messing, billeting, armory, and others, and fuse them to be 
carried or accessed using a single card? How will the 
cards be issued and tracked? How will lost cards be taken 
out of the system and replacement cards issued? Failure to 
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address these processes prior to implementing this 
technology could result in significant problems. 

(3) The Marine Corps' Total Force System (MCTFS) 
Initiatives. One such initiative is with regard to Unit 
Diary (UD) ownership. Information contained in MCTFS is 
updated periodically based on information submitted via UD 1 . 
Currently, only a unit's personnel administration section 
submits information via UD. All other sections that need to 
post information to MCTFS must submit the disparate source 
documents to the personnel section for processing. The 
information contained on these source documents is then re¬ 
entered into the UD's proprietary format for reporting to 
MCTFS. Once a UD is prepared, a hard copy is printed and 
submitted to the unit's Personnel Officer for review and 
certification. Once certified, the UD is forwarded for 
incorporation into MCTFS. However, MCTFS is not a real¬ 
time system. For non-pay related information, there is a 
delay in preparing, certifying, and submitting UD's. Pay 
related information is handled somewhat differently and is 
only incorporated this twice each monthly through the 
update and extract process. This is a source of 

inefficiency and causes problems most often seen with 
regard to personnel pay and promotion. 

Total Force Administration System (TFAS) represents a 
new initiative in the realm of Marine Corps Personnel 
Administration. TFAS actually is a front-end system that 
is tied to MCTFS. Individual Marines will be able to 
change or request changes to certain information via the 

1 Unit Diaries (UD's) contain information reported in a proprietary 
format which automates the process of updating information contained in 
MCTFS. 
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web rather than relying on Marines working in his or her 
unit's personnel administration section. The unit 
Commander (e.g. company or battalion commanders) will have 
the ability to enter such things as training and morning 
report information directly into the system. Access at 
this level is referred to as second echelon access. Third 
Echelon will comprise three TFAS centers located at the 
major installations. These centers will submit information 
requiring expertise or oversight. Forth echelon consists 
of call centers which will be available 24 hours to provide 
assistance to system users. The highest echelon, fifth 
echelon, is Headquarters, U.S. Marine Corps (M&RA). 

How can TFAS best be used to increase the efficiency 
of current personnel administration processes? Considering 
the plethora of information that must be updated in MCTFS 
on a routine basis, removing any bottle necks and speeding 
up the process would result in more accurate, timely 
information being maintained and saving numerous man-hours 
of labor. 

(4) Personnel Housing Assignment. The recent push to 
privatize base housing presents a good opportunity to 
review current housing management processes. Again, there 
are numerous sources that may be accessed to determine when 


current 

residents 

will 

be 

moving and 

when future service 

members 

who 

want 

to 

be 

assigned to 

base housing 

will 

arrive. 

How 

can 

we 

better manage 

and coordinate 

this 


information. 

(5) Repair parts/supply requisitioning process. This 
area has seen numerous initiatives in recent years. From 
migrating to a more just-in-time inventory type system to 
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eliminating non-value added steps, improvements have been 
made. However, it is still a problematic area where 
efficiencies can be gained and increased effectiveness may 
be realized. 

These are just a few problem areas within the military 
that could benefit from the application of a BPR tool such 
as KOPeR-lite to develop process redesigns. The results of 
implementing more efficient, effective process may include: 

- Cost savings; 

- Reduction in the number of personnel needed in the 
execution of various processes; 

- Increased customer satisfaction. (The customer 
ranges from individual service members to the 
nation, from individual commands to civilian 
contractors.) 


G. SUMMARY 


The 

goal of 

BPR is to 

produce 

quantum 

leap 

improvements in the 

efficiency 

and effectiveness 

in 

business 

processes. 

The need to 

conduct 

BPR has 

not 


diminished since the term was originally coined. Rather, 
the significant improvements in the realm of technology, 
rapid improvement in information availability (driven 
largely by advances in technology) , as well as the 
implementation of new technologies without changing 
underlying processes all necessitate continued or renewed 
BPR efforts. 

Davenport provides us with a framework within which to 
pursue BPR efforts. KOPeR-lite provides us with a tool to 
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automate two knowledge intensive steps in the BPR process: 
(1) pathology diagnosis and (2) transformation matching. 
The goal of the subsequent chapter is validate the benefit 
of KOPeR-lite. 


20 



III. BUSINESS PROCESS REENGINEERING EXPERIMENT 


A. EXPERIMENTAL DESIGN 

The hypothesis to be tested in the experiment is: 
Will using KOPeR-lite result in BPR novices producing (1) a 
greater number of redesign alternatives and (2) redesigns 
that are higher in quality with regard to feasibility and 
overall impact? 

Two test groups are drawn from the pool of graduate 
students attending the Naval Postgraduate School. Students 
selected to participate in the experiment are screened to 
ensure novice status, meaning they had no prior BPR 
experience, and each receives a one-hour period of 
instruction on re-engineering. This period of instruction 
was given well in advance of the laboratory period where 
they would be tasked with developing redesigns for the case 
contained in Appendix A. This afforded the students the 
opportunity to assimilate the information presented during 
the period of instruction. 

The experiment was conducted during the course of a 
single, two hour long laboratory period during which the 
students are instructed to develop as many distinct 
redesign alternatives as they can. Given the time 
limitation, speed of redesign generation is a significant 
factor in the number of redesigns generated per subject. 
Effectiveness of the redesigns is another major 
consideration. 

For the laboratory period, the first group is tasked 
to generate redesigns without the use of KOPeR-lite and the 
second with KOPeR-lite. 
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The redesigns generated are then analyzed based on the 
following criteria: 

• Number of redesigns generated 

• Delinearization of process flows 

• Enablers: 

• Information technology 

• Organizational Design (other than through 

the injection of IT) 

• Change in the number of activities 

• Change in the number of feedback loops 

• Change in the number of handoffs 

• Clarity of the redesign, and 

• Impact 

1. Number of Redesigns Generated 

Redesigns needed to be distinct in that a reader 
should be easily able to determine where one redesign 

description ends and another begins. In some cases, 
redesigns are presented simultaneously in a fashion such 
that one is unable to discern which features belong to 
which redesign. In such cases, the analyst was forced to 
use his or her best judgment to determine the number of 
redesigns generated by the experimental subject. 

2. Delinearization 

Delinearization means that two or more activities that 
were carried out sequentially in the baseline process are 
carried out simultaneously in the redesign. Activities 
could be grouped together in the redesign without 

necessarily resulting in delinearization. For example, the 
design and test activities could be merged into a single 
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cell where the coders must still 


"software development" 
wait for the designers' output before they can commence 
work. Therefore, the flow is still sequential. However, 
if this "software development" cell uses cyclic development 
or modular design, the designers could pass on to the 
coders the design for a single module so that they may 
commence coding while the designers continue designing 
additional modules. In this case, delinearization has been 
incorporated into the redesign. A binary (yes/no, 1/0) 
determination was made for this criterion. 

3. Enablers 

An enabler is anything that results in increased 
process efficiency or effectiveness. Enablers include, but 
are not limited to: information technology such as shared 
databases, computer networks, electronic mail (e-mail), 
automated forms, video teleconference, computer aided 
software engineering (CASE) tools; organizational design 
enhancements such as grouping of related activities to 
facilitate information exchange and work coordination or 
inclusion of a case manager who would have oversight over a 
group of activities; and human resource factors such as 
enhanced training or other personnel support initiatives. 
Each example of an enabler incorporated into a redesign was 
counted and the overall number of enablers per redesign 
tallied. An enabler that was used multiple times within a 
single redesign was only counted once. For example, e-mail 
may be used in four activities within the redesign, however 
the e-mail enabler is counted only once for that redesign. 
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4. Change in the Number of Activities 

The number of activities in a redesign process may 
increase or decrease from the number included in the 
baseline. It is hoped that by adding or removing an 

activity, the overall efficiency and effectiveness of the 
process workflow will be enhanced. For example, the sales 
activity might be eliminated as superfluous under the 

supposition that customers can communicate their software 
needs to the software development company via telephone or 
a website vice going through a software development 
marketing agent. 

5. Change in the Number of Feedback Loops 

A feedback loop occurs any time information or a 

product from one activity is provided to an activity 
earlier in the process. For example, if the Independent 
Verification and Validation (IV&V) activity finds a flaw or 
deficiency in the software product, IV&V's finding must be 
sent to earlier activities (e.g.. Design and/or Code) so 

that the deficiencies can be addressed. Sometimes, as in 
the case of micromanagement, excessive feedback loops 
inhibit efficiency and should be eliminated. 

6. Change in the Number of Handoffs 

The number of handoffs occurring in the process 
workflow is dependent on the overall number of activities 
as well as the manner in which they are carried out. An 
example of how the number of handoffs may be reduced while 
keeping the overall number of activities the same is 
depicted in Figure 3-1. 
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Redesigned Process Workflow 



A: Sales 

B: Requirements 
C: Design 
HandafT 

"1 : Activity Grouping 


D: Code 
E: Test 
F: IV &V 


O: 


: Activity 


Figure 3-1. Redesign Example Highlighting a Reduction in 

the Number of Handoffs 


In this example, activities B and C as well as D and E are 
combined into two integrated activities. By doing this, 
the number of handoffs is reduced from five to three. 


7. Clarity of the Redesign 

Essentially, this is the ease with which one is able 
to discern the features of a proposed redesign. A scale 
from one to three was used. The following criteria were 
applied in attempts to objectify this largely subjective 
metric: 

• 1 - not very clear; no redesign graphic, redesign 
metrics are not included, textual description 
fails to enhance a reader's ability to discern 
what the author is trying to convey. 

• 2 - clear; a redesign graphic or metrics are 

provided, textual description provides the reader 
with a good understanding of the author's 
redesign. Redesigns where the author provided 
both a redesign graphic and metrics but provided 
a mediocre textual description are also assigned 
a value of clarity value of 2. 
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3 - very clear; both a redesign graphic and 
redesign metrics are included and the textual 
description provides the reader with an 
exceptionally clear mental picture of the 
author's redesign. 


8. Impact 

A scale from one to three is used. The following 
criteria were applied to objectify this basically 
subjective category: 

• 1 - infeasible or feasible but negligible impact 

• 2 - feasible and moderate gains in efficiency and 
effectiveness of the process workflow anticipated 

• 3 - feasible and significant gains in efficiency 
and effectiveness of the process workflow 
anticipated 


B. ASSESSMENT PROCEDURE 

The software development case contained in Appendix A 
was presented to two groups of graduate students at the 
Naval Postgraduate School. The redesigns produced by each 
experimental subject were then analyzed based on the 
criteria listed in Section A above. Two separate analyses 
were conducted: one by the author and another researcher. 
Once these separate analyses were completed, both 
researchers met to discuss their individual findings and to 
generate a single, integrated analysis. Once the 
integrated analysis was generated, several methods of 
statistical manipulation were applied to the quantitative 
data. The outcome of this analysis provides the basis for 
the conclusions drawn at the end of this chapter. Appendix 
B documents individual and integrated analyses as well as 
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providing explanatory comments documenting the rationale 
behind the quantitative assessments. 

C. EXPERIMENTAL RESULTS 

The data contained in Appendix B were then distilled 
and entered into a spreadsheet for statistical analysis. 
First the independent analyses were reviewed to determine 
interjudge reliability. Following this, an integrated 

analysis was conducted to determine whether or not KOPeR- 
lite provided the BPR novices in the experimental group 
with any quantifiable benefits. 

1. Interjudge Reliability 

As stated above, one of the first goals was to 
identify any significant interjudge differences. Three 
basic metrics were used: arithmetic mean, standard 

deviation, and correlation. Ideally, there would be no 
difference in arithmetic means or standard deviations, and 
unity correlation for each variable between the two 
researchers would exist. Departures from the "ideal" 
results are discussed below. 

a. Delinearization 

Delinearization was a binary criterion. A 

redesign either did or did not apply delinearization, 
resulting in the assignment of a 1 or 0 respectively. 
Differences stem from an initial difference of opinion 
about what constituted delinearization (note the 
particularly low correlation of 0.22415) . It was decided 
that a value of 1 would be assigned only for those 
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redesigns where activities were explicitly identified to be 
done in parallel or where modular development techniques in 
conjunction with a development team concept. After 
reconciling these initial differences in opinion, the two 
researchers attained 98.7% agreement on delinearization 
assessment. 


b. IT Enablers 

Prior to discussing their ratings, the 
correlation between the two researchers on this criterion 
is 0.86 indicating that significant agreement exists. 
Following discussions, the two researchers attained 100% 
agreement. 


c. Non-IT Enablers 

One judge focused exclusively on IT enablers and 
failed to take into account any other enablers incorporated 
in the various redesigns. Since data for this criterion 
was only available from one of the two judges, no 
conclusions with regard to interjudge reliability can be 
drawn. Following discussions to reconcile difference, 
however, the two researchers attained 100% agreement. 

d. Non-value Added Activities Removed 

Prior to discussing their ratings, the 
correlation between the two researchers on this criterion 
is 0.96 indicating that significant agreement exists. 
Following discussions, the two researchers attained 100% 
agreement. 
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e. Change in Number of Hand-offs 

Prior to discussing their ratings, the 
correlation between the two researchers on this criterion 
is 0.84 indicating that significant agreement exists. 
Following discussions, the two researchers attained 100% 
agreement. 


f. Clarity 

Significant differences existed at first between 
the two judges with regard to clarity (note the somewhat 
low correlation of 0.53 between their two sets of ratings 
prior to discussion). This can be explained by the 
differences in techniques the two judges applied to assign 
a value this criterion. One researcher established a clear 
set of criteria, as outlined above, which was applied to 
each redesign to determine what value should be assigned. 
The other researcher used a somewhat less systematic, more 
qualitative assessment in the assignment of clarity scores. 
Following discussions to reconcile differences between the 
two researchers' scores, 100% agreement was attained. 

g. Impact 

Prior to discussing their ratings, the 
correlation between the two researchers on this criterion 
is 1.0 indicating that the ratings assigned by both 
researchers matched exactly. 


Integrated Analysis 


2 . 


29 



After reaching consensus between the two analyses, an 
integrated analysis was performed. First, a correlation 


matrix was developed to see if any pairs of criteria seemed 
to move together. The results of this analysis are 
contained in the table below. 


Correlation 

Matrix 

Redesigns 
per subject 

Delinearization 
(0=N; 1=Y) 

IT enablers 

Non-IT 

enablers 

non-value 
added items 
removed 

change in # of 
feedback loops 

change in # of 
hand-offs 

Clarity 

Impact 

Delinearization 

N/A 

XXX 

-0.094011639 

0.519674637 

-0.171789602 

-0.150647456 

-0.129574841 

0.061349982 

0.342864196 

IT enablers 

N/A 

XXX 

XXX 

-0.045950545 

-0.276677323 

-0.164370749 

-0.315067908 

0.067106949 

0.501988309 

non-IT 

enablers 

N/A 

XXX 

XXX 

XXX 

0.013144741 

-0.141064123 

-0.026438973 

0.242303425 

0.511553536 

hi 

N/A 

XXX 

XXX 

XXX 

XXX 

0.378130105 

0.648540606 

-0.027253437 

-0.220458969 

feedback loops 

N/A 

XXX 

XXX 

XXX 

XXX 

XXX 

0.619683511 

-0.128009047 

-0.195219569 

handoffs 

N/A 

XXX 

XXX 

XXX 

XXX 

XXX 

XXX 

-0.162987375 

-0.341127616 

clarity 

N/A 

XXX 

XXX 

XXX 

XXX 

XXX 

XXX 

XXX 

0.395138052 

impact 

N/A 

XXX 

XXX 

XXX 

XXX 

XXX 

XXX 

XXX 

XXX 


Table 3-1. Correlation Matrix. 


Numbers approaching unity would signify that the two 
criteria move together; that perhaps they are measuring the 
same thing. As can be seen in the table above, such is not 
the case in this analysis. This provides evidence that the 
eight criteria being looked at are not redundant with one 
another. 

The next step was to test the null hypothesis: "KOPeR- 

lite does not provide any significant benefit to novices 

developing BPR redesigns." To test this hypothesis, the 

data set was first broken down into four subsets: (1) 

Without KOPeR Group (with outliers), (2) Without KOPeR 

Group (without outliers), (3) With KOPeR Group (with 

outliers), and (4) With KOPeR Group (without outliers). 

"Outliers" refers to the subjects who analyzed the baseline 

process in a significantly different manner than the 

majority of subjects. The typical baseline analysis broke 
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the process down into six activities with five handoffs and 
two feedback loops as is depicted below. 



Figure 3-2. Typical Baseline Analysis for the Software 
Development Case (see Appendix A) 

The arithmetic mean, standard deviation and confidence 
intervals for each of the metrics for the two "Without 
KOPeR-lite" groups were then calculated. Confidence 

intervals were set at both 0.95 and 0.90. Next, the 
arithmetic mean and standard deviation for each of the 
eight criteria in the two "With KOPeR" groups were 
calculated. These means were then compared to the 

confidence intervals of their respective "Without KOPeR" 
sets to identify any significant differences. Where means 
for the "With KOPeR" subsets fell outside the confidence 
intervals for the "Without KOPeR" subsets, we have evidence 
that KOPeR does yield significant benefit to the BPR 
novices in this experimental group. A textual summary of 
the results is provided below. 
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W I T J 

H Outliers 

Without 

KOPeR 

With KOPeR 

95% 

confidence 

Interval 

90% 

confidence 

Interval 

70% 

confidence 

Interval 

# redesigns per 
subject 

2.1 

1.94 

Within 

Within 

■gg 

Delinearizatio 

n 

0.2727 

0.2727 

Within 

Within 


IT enablers 

3 

3.6363 

Above 

Above 

Above 

Non-IT 

enablers 

.97727 

1.2424 

Within 

Above 

Above 

Non-value 
added items 
removed 

0.15909 

-1.4545 

Below 

Below 

Below 

Change in # of 
feedback loops 

-0.3409 

-.57575 

Within 

Within 

Within 

Change in # of 
handoffs 

-1.8409 

-2.7878 

Below 

Below 

Below 

Clarity 

1.6136 


Above 

Above 

Above 

Impact 

1.81818 


Within 

Within 

Within 


Table 3-2a. Comparison of Means for the "With Outlier" 

Groups. 



WITHOUT Ou 

t 1 i e r s 

Without 

KOPeR 

With KOPeR 

95% 

confidence 

Interval 

90% 

confidence 

Interval 

70% 

confidence 

Interval 

# redesigns per 
subject 

2.06 

1.93 

Within 

Within 

Below 

Delinearizatio 

n 

0.324324 

0.24137 

Within 

Within 

Below 

IT enablers 

2.97297 

3.34482 

Within 

Within 

Within 

Non-IT 

enablers 

1.027027 

1.31034 

Within 

Above 

Above 

Non-value 
added items 
removed 

-0.027027 

-0.20689 

Below 

Below 

Below 

Change in # of 
feedback loops 

-0.16216 

-0.17241 

Within 

Within 

Within 

Change in # of 
handoffs 

-1.135135 

-1.44827 

Within 

Within 

Below 

Clarity 

1.567567 

1.89655 

Above 

Above 

Above 

Impact 

1.810810 

1.86206 

Within 

Within 

Within 


Table 3-2b. Comparison of Means for the "Without 

Outlier" Groups 


For criteria where the With KOPeR-lite group produced 
superior results, the appropriate cell in tables 3-2a and 
3-2b are lightly shaded. For those with no significant 
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difference, the cell contains diagonal hatches and those 
where the With KOPeR-lite group's performance was inferior, 
the cell contains cross-hatches. 

D. FINDINGS 

Based on the results summarize in Table 3-2, several 
differences between redesign performance of the two subject 
groups (i.e.. With and Without KOPeR-lite) are significant 
and worthy of comment. 

Looking first at the With-Outliers (i.e., whole) 
Group, notice the KOPeR-lite group employed significantly 
more IT enablers (95% level) and non-IT enablers (90% 
level). This KOPeR-lite group also decreased the number of 
handoffs significantly (95% level), and the redesign 
descriptions of this group were significantly clearer (95% 
level). These are all considered positive results, in that 
such redesigns are generally considered superior according 
to contemporary re-engineering theory. 

Alternatively, notice the number of non-value-added 
items removed as significantly lower for the KOPeR-lite 
group. Since non-value-added items are, by definition, not 
essential for process performance, a superior redesign 
would remove more such items, not less. Hence, the KOPeR- 
lite group appears to perform worse than the control group 
according to this criterion. 

Notice the change in number of feedback loops is not 
significantly different between the two groups nor is the 
difference in number of redesigns generated per subject. 
Most surprising is that, despite the "superior" theoretical 
redesign performance noted above, the difference in 
potential impact of redesigns developed across the two 
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groups is also insignificant. Thus, although the use of 
KOPeR-lite produces several differences that are considered 
positive in terms of re-engineering theory, these empirical 
results suggest such theory may require an update, for 
judged redesign performance is indistinguishable between 
the with- and without-KOPeR-lite groups. 

These results suggest that the key benefits of using 
KOPeR-lite stem principally from the use of enablers and 
clarity of redesign descriptions. And, although the 
reduction in process friction expected from decreasing 
handoffs in the process should improve performance in terms 
of cycle time, such performance improvement was not judged 
to be significant in terms of redesign impact. 

Results of the without-outliers groups are similar, 
except that many of the differences are not as significant 
between the With- and Without-KOPeR-lite Groups when they 
are removed. For instance, the number of IT enablers and 
change in the number of handoffs are considerably less 
significant between these groups than between the With- 
Outliers Groups as noted above. However, the difference in 
delinearization between the With- and Without-KOPeR-lite 
Groups is marginally significant when the outliers are 
removed. Consistent between the with- and without-outliers 
analyses are differences in non-IT enablers used and 
clarity of the redesigns. Also as above, differences in 
impact between the With- and Without-KOPeR-lite Groups are 
insignificant. Thus, some KOPeR-driven differences in 
redesign performance noted above are mitigated when 
outliers are removed, but the difference in clarity of 
redesign descriptions remains prominent. These findings 
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suggest implications in terms of KOPeR-lite use as 
discussed below. 

Referring back to the data contained in Table 3-1, 
there are some correlations that warrant some discussion. 
For instance, the correlation between "change in number of 
handoffs" and both "non-value added items removed" and 
"change in number of feedback loops" are 0.65 and 0.62 
respectively. Upon reflection, however, this intuitively 
makes sense. If you remove processes, the likelihood that 
number of handoffs will be reduced it pretty high. 
Likewise, if you reduce the number of handoffs, there is a 
reasonable chance that one or more feedback loops may be 
eliminated. 

Additionally, the correlation between "Impact" and 
both "IT enablers" and "Non-IT enablers" are higher than 
most of the other correlations with values of 0.50 and 051 
respectively. Again, this correlation seems somewhat 
intuitive: The greater the number of enablers incorporated 
into a process redesign the greater the impact the redesign 
can be expected to effect when implemented. 


E. SUMMARY 

The findings from this experiment revealed a number of 
anticipated results as well as surprises. We had 

anticipated KOPeR-lite use to promote incorporation of 
additional enablers into process redesigns, for the system 
can augment a person's memory and level of redesign 
expertise. For instance, where a novice in terms of 
process redesign may not be aware of certain enablers 
(e.g., case manager, delinearization), KOPeR-lite can 
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suggest the use of such enablers when its diagnostics imply 
they are appropriate. Additionally, because KOPeR-lite 
employs a consistent, systematic approach to process 
redesign (e.g., measurement, diagnosis, matching), we 
anticipated that redesign descriptions would reflect some 
of this systematic consistency in terms of clarity. These 
can both be viewed as positive benefits stemming from 
KOPeR-lite use. 

Alternatively, we were quite surprised that KOPeR-lite 
did not produce significant differences in terms of 
potential impact of the redesigns generated. Following re¬ 
engineering theory, we anticipated that incorporation of 
additional enablers as noted above would lead to greater 
impact in terms of performance improvement. Although the 
impact associated with redesigns produced by the With- 
KOPeR-lite Groups were indeed judged to be greater than 
those generated by the Without-KOPeR-lite Groups, we found 
no significant differences in terms of this measure. 

One explanation for this is the relatively small 
sample (n = 44) employed in the experiment. It could be 
that, with more test subjects, the positive differences in 
terms of redesign impact would become significant. Perhaps 
a future study could test this supposition. 

Another explanation could be that the judges' criteria 
used to score the various redesigns according to this 
criterion were flawed. It could be that, despite the 
judges drawing from re-engineering theory to assess the 
potential impact of various redesigns, physical processes 
redesigned using KOPeR-lite may indeed exhibit 
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statistically significant performance improvement. But 
this also remains for a future study to examine. 

A third explanation is, KOPeR-lite lacks the kind of 
strong domain knowledge required to make a significant 
difference in terms of novices' redesign performance. With 
the incorporation of additional process measures, 
diagnostic tests and redesign rules, for instance, this 
system may prove to enhance redesign performance in ways 
the current KOPeR-lite system cannot. Examining this 
possibility will require modification of KOPeR-lite and 
another experiment to assess the impact of the modified 
system on redesign performance, which as above, is a matter 
for a future study. 

In terms of the present research, KOPeR-lite will be 
used to take advantage of the things it does well (e.g., 
identifying enablers, reducing handoffs, clarity of 
redesign descriptions), but the researcher will not rely 
upon KOPeR-lite alone. Redesign of the Marine Corps 
process is presented in the following section. 
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IV. THE PERSONNEL ASSIGNMENT PROCESS IN THE USMC 


A. DESCRIPTION OF THE CURRENT PROCESS 

One process that has been identified by personnel 
management experts in the Marine Corps as problematic is 
the permanent change of station (PCS) orders process for 
officers, particularly after their first tour of duty. 
This problem has been articulated by not only individuals 
who participate in the planning and assignment process, but 
also by the people who's lives and careers are most 
prominently affected by how well (or poorly) the process is 
carried out. Problems include numerous databases that 
capture various subsets of information where these 
databases are loosely, if at all, integrated. As a result, 
the information contained in various reports generated by 
tapping into the databases does not reflect an accurate 
picture of the current manning situation. Numerous issues 
plague officers who are due for orders. Two of the most 
common complaints are with regard to the timeliness with 
which they are issued orders and the inability of 
individual officers to access a list of current and 
projected billet vacancies so that they can more precisely 
articulate their desires for future assignments 2 . 

Before we can consider how and when individuals are 
issued PCS orders, we must first understand the Marine 
Corps underlying framework for manpower management. Table 
of organizations (T/O's) are established for all units. 
T/O's are listings of all the jobs associated with a 

2 The U.S. Air Force has a mechanism in place where all officers can 
access a current list of available billets and communicate directly 
with the individual or department responsible for making future 
assignments. 
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particular command. Information contained on a T/O 
includes: T/O number, billet line number, billet rank, and 
billet description. 

Each unit is then assigned a staffing priority level. 
These levels are: (1) V-unit, which are units that 
consistently maintain a high state of readiness so that 
they may deploy at a moment's notice, (2) priority, (3) 
excepted, which include joint billets and other critical 
billets, and (4) all others. V-units are staffed at 100% 
of their authorized strength. Priority commands are 
staffed at 95%, excepted commands at 99%, and all others at 
80%. 

Another source of information used in managing 
personnel is the Marine Corps Total Force System (MCTFS). 
This database contains personal information about each and 
every Marine. Included are such items as: name, social 
security number, date of birth, rank, date of rank, current 
address, phone number, record of emergency data 
information, blood type; training information such as 
rifle, pistol, swim qualifications, current physical 
fitness test (PFT) results, primary and secondary military 
occupational specialty codes; uniform size information for 
such things as gas mask, camouflage blouse, camouflage 
trousers; and current tour information such as T/O number, 
line number, billet rank, billet name, billet MOS, and date 
current tour began among others. For the purposes of this 
chapter, the personal information and current tour 
information will be of primary importance. 

Based on the information contained in T/O's, 
established staffing goals, and MCTFS, a Personnel 
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Management Report 3 (PMR) is generated. One of the uses of 
this report is to plan future personnel assignments. 

In order to determine future assignments, the 
following are key elements of information: 

• what billets are to be staffed, 

• which of these billets are currently vacant, and 

• when individuals are projected to rotate out of 

their current assignment. (This can be 

calculated by adding the appropriate tour length 
to an individual's "date current tour began" 
(DCTB) entry contained in MCTFS.) 

A tour of duty is generally three years in length of 
assignments within the continental United States (CONUS) 
and outside of the continental United States (OCONUS) 
accompanied tours, and one year for OCONUS unaccompanied 
tours. Though the process is essentially the same 

regardless of tour length or location, for simplicity, THE 
focus is on three year CONUS or accompanied OCONUS tours 
for the remainder of this section. 

Once an individual has spent two years in their 
current assignment, they have fulfilled the obligated 
service requirement incurred for their most recent CONUS 
PCS move. HQMC can, therefore, begin considering them for 
a future assignment though their goal is for individuals to 
serve three years in their current assignment before 
ordering them to report to a new command. However, since 


3 The PMR is a reporting mechanism developed by a gentleman named Mr. 
Marsh back in approximately 1966. It reports such information as the 
current personnel inventory, proper staffing inventory (which si driven 
by such factors as yearly authorized strength, yearly on hand strength, 
T/0 allowance, and T/0 staffing goal, as well as individual's rank, 
MOS, etc.. It is connected to MCTFS only at the front- and back-ends, 
but doesn't directly interact with MCTFS. For instance, information 
about a person on the PMR will not "trigger" a move in MCTFS. 
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their service obligation has been fulfilled, these 
individuals are referred to as "movers." 

In the orders process, there are four primary 
stakeholders. These are the "mover," monitors 4 , as well as 
the losing and gaining commands. 

At about the two-year mark, the mover has the option 
of communicating his or her follow-on assignment 
preferences to his or her respective monitor. Future duty 
preferences can be communicated to the monitor in any 
number of ways, to include: 

• the duty preference codes listed by an individual 
on their performance evaluations (these 
eventually get reported into the MCTFS); 

• submitting duty preference via the website 

maintained by the Manpower Management Officer 
Assignment (MMOA) branch (a standalone database 
accessible only by MMOA staff and individuals 
updating their personal record) ; 

• email or telephone communications between the 

monitor and individual officer, or 

• conversations held when the monitor and 

individual officers are able to meet in person 

(such as during MMOA's annual "road show" where 
all the monitors visit the major installations 
with the primary intent of meeting with and 
discussing future assignments with individuals 
who are nearing the end of their current tour). 

Note that only one of these methods (the listing of 

duty preference codes on one's performance evaluation) 


4 Monitors are individuals working in the HQMC, Manpower and Reserve 
Affairs, Manpower Management [MRA (MM)] section that manage personnel 
assigned the military occupational specialties (MOS's) they've been 
assigned to manage. They must match officer desires with needs of the 
Corps in the short run, but also to ensure that a sufficient number of 
officers are trained, experienced, and qualified to command and staff 
the Corps in the future. 
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results in an update to the information contained in MCTFS, 
the database used to generate the PMR. 

Currently, the mover does not have access to 
information about which billets are vacant or due to become 
vacant. Only the monitor has access to this information. 

Armed with a list of movers, the movers' preferences, 
and a list of current and projected billet vacancies, the 
monitor begins the process of identifying which individuals 
will be assigned to current and upcoming billet vacancies. 
The monitor must apply the criteria outlined in MCO 
P1300.8G Ch 4 in determining future assignments. 

• needs of the Marine Corps, 

• MOS/Billet variety 5 , 

• Availability of the individual, 

• Overseas control date (OCD) 6 , 

• Seniority 7 , and 

• Individual preferences. 


5 Monitors take care to ensure officers have the opportunity to 
perform in their MOS including command at the junior ranks, and in 
other staff and instructor billets, as well as have the opportunity to 
attend appropriate military education, to ensure they are "fully 
qualified." Needs of the Corps also demand officers be assigned to 
recruiting, instructor. Marine Corps Security Force, Marine Corps 
Recruit Depot, acquisition, joint, and Navy staff duty. 

® The Overseas Control Date (OCD, or OSCD on the Master Brief Sheet) 
remains a fair way to determine an officer's place in the "queue." The 
OCD may take precedence over other assignment factors considered by the 
monitor. The monitor will determine the number of overseas "fills" 
required by MOS, and compare that to officers' OCD. The older the 
officer OCD, the more likely the assignment to an overseas tour. 

7 An officer's seniority must be taken into account to lessen the 
possibility they will not be promoted out of the assignment prior to 
completing the prescribed tour length. 

8 Note that individual preference is the last criteria applied when 
the monitor makes assignments. 
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In addition to the criteria outlined in P1300.8G Ch 4 


the monitor must also take into account the following 
criteria outlined in MMOA's Officer Development Handbook: 

• Staffing Goal 9 

• Authorized Strength Report (ASR) 10 , 

• Time in geographic location 11 , and 

12 

• An officer's availability . 

Per MMOA's Officer Development Handbook: 

9 The Staffing Goal is the "best" distribution of available Marines 
to all authorized billets. Each year, a computer Staffing Goal Model is 
run to produce a preliminary "fit" of available officers by grade and 
PMOS to authorized billets. MMOA's staffing goal model combines those 
billets that CG, MCCDC has authorized to be manned with the available 
officer inventory. Monitors manually review the model and make 
necessary changes. 

10 The Authorized Strength Report (ASR) is a CG, MCCDC (TFSD) 

document produced semi-annually which completes the manning process. 

The ASR converts the macro Troop List manning numbers into the micro 
level of detail. Specifically, the ASR allocates manning to units 
(MCCs) by grade and MOS. Remember, manning is about billets, not 
people. Through the manning process, the Marine Corps is "buying" xxx 
number of billets. TFSD then determines what percent of those 
authorized billets are actually filled. The ASR is the linking document 
between MCCDC and M&RA. The ASR is delivered to MM Division for use in 
the staffing goal models (the staffing process-distribute current 
inventory) and MP Division for input into the GAR (the development 

manpower plans process-build future inventory). 

11 Three years has long been the standard tour length. ALMAR 075/96 

of 4 Mar 96, Increasing the Number of 4 to 5-Year geographic location 
tours, outlined the "standard" 3-year policy, and published the CMC's 
guidance for 4 to 5-year tours, and the analysis by the 1995 General 

Officer Symposium. The consensus of the Corps' senior leaders indicated 

that an increase in the number of 4 to5-year geographic location tours 
would benefit both the Corps and the individual Marine by increasing 
unit stability, reducing family turbulence and reducing PCS costs. The 
CMC approved the General Officer Symposium recommendation and directed 
that the number of 4 to 5-year geographic location tours be increased 
whenever the needs of the Corps and individual preferences can be 
accommodated by the longer tour. Extended tours would include extension 
on station with the same command, split tours between commands at the 
same installation, and low cost PCS and PCA orders between commands in 
the same geographic location. While this change is a clear move toward 
an increase in tour length, it is not a guarantee that all Marines will 
serve 4 to 5 years at the same command or in a particular geographic 
location. Officers interested in remaining in place for longer tours of 
duty should inform their monitor. 

12 An officer's availability will depend on prescribed tour lengths, 
internal and external billet requirements, and allowable exceptions to 
assignment policy. Obviously, monitors must minimize the number of 
assignments that require tour length waivers. 
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Once a monitor has a potential officer for an 
assignment, the assignment enters an approval 
process that varies with type and grade. 

A company grade monitor's potential assignment 
for a warrant officer, chief warrant officer, 
lieutenant, or captain is reviewed by a "center 
desk" major as a quality assurance check and 
approval. If the assignment requires a waiver of 
policy, it is reviewed by the aviation or ground 
section head (a lieutenant colonel), and then can 
be approved by the Officer Assignment Branch Head 
(a colonel). If the assignment involves a move at 
2 years or less, the Personnel Management 
Division Director (a major general) reviews it. 

If the assignment is to a joint or acquisition 
billet, the Joint Officer Management Officer or 
Acquisition Management Officer reviews the 
assignment and provides a recommendation to the 
Officer Assignment Branch Head. 

A field grade officer's assignment is reviewed by 
the Aviation or Ground Monitor Section Head (a 
lieutenant colonel), by the aviation or ground 
colonel's monitor (a colonel), and by the Officer 
Assignment Branch Head (a colonel). If the 
assignment is to a joint or acquisition billet, 
the Joint Officer Management Officer or 
Acquisition Management Officer reviews the 
assignment and provides a recommendation to the 
Officer Assignment Branch Head. The Branch Head 
makes a recommendation to the Personnel 
Management Division Director (a major general) 

Once the assignment proposed by the monitor has be 
approved, the monitor then issues orders 1 ". 

Unlike with orders for enlisted services members which 
are issued using the Automated Order Writing Process 


■*■3 Orders are the authoritative document that tells the mover: (1) 
when he or she is to detach from their currently command, (2) what 
command he or she is to report to (3) when he or she is to report to 
their future command, (4) and under what set of appropriation data the 
orders are to be executed. 
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System(AOWPS) 14 , orders for officers can be issued using any 
number of ways, to include: (1) AOWPS, (2) verbal or 

telephonic (these are eventually backed up by written 
orders of some type), (3) e-mail, (4) FAX, (5) Defense 
Message Service (DMS), (6) letter-type. Of these methods, 
only the first results automatically updating the 
information contained in MCTFS. For all other methods of 
issuing orders, MCTFS must be manually updated, either by 
HQMC prior to the officer's detaching date or by the 
receiving command once he or she reports in. 


The potential delay in updating the information 
contained in MCTFS poses some problems. Until MCTFS is 
updated, the information contained in the PMR will not be 
accurate. If the PMR is inaccurate, the effectiveness of 
that report as a planning tool is greatly diminished. If 
the PMR is inaccurate, the staffing goal model used in the 
Manpower Management section at HQMC will not portray an 
accurate picture. 


14 Three years has long been the standard tour length. ALMAR 075/96 
of 4 Mar 96, Increasing the Number of 4 to 5-Year geographic location 
tours, outlined the "standard" 3-year policy, and published the CMC's 
guidance for 4 to 5-year tours, and the analysis by the 1995 General 
Officer Symposium. The consensus of the Corps' senior leaders indicated 
that an increase in the number of 4 to5-year geographic location tours 
would benefit both the Corps and the individual Marine by increasing 
unit stability, reducing family turbulence and reducing PCS costs. The 
CMC approved the General Officer Symposium recommendation and directed 
that the number of 4 to 5-year geographic location tours be increased 
whenever the needs of the Corps and individual preferences can be 
accommodated by the longer tour. Extended tours would include extension 
on station with the same command, split tours between commands at the 
same installation, and low cost PCS and PCA orders between commands in 
the same geographic location. While this change is a clear move toward 
an increase in tour length, it is not a guarantee that all Marines will 
serve 4 to 5 years at the same command or in a particular geographic 
location. Officers interested in remaining in place for longer tours of 
duty should inform their monitor.Per MCO P1000.8, par 1201.4, "The 
Automated Orders Writing Process (AOWP) ...is designed to allow HQMC to 
forward PCS orders data to a Marine's command via MCTFS. AOWP is the 
primary method of issuing orders for enlisted Marines." No such 
standard exists for issuing orders to officers. 
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The process discussed above can be roughly distilled 
into the activities pictured below: 

A process representation is provided below and a 
textual description follows: 
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* The PMR is software tool that generates a report having the same 

name. 


15 tiqii designates the performing organization in the process (e.g.. 
Sales Department, Requirements Department) 

16 H^n designates the agent role in the process (e.g.. Sales Agent, 
Requirements Agent) 

"S" designates the information technology employed for support in 
the process (e.g., word processor (WP), computer-aided software 
engineering (CASE) tool) 

18 iiqh designates the media/technology employed for communication in 
the process (e.g., phone, report) 
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Figure 4-1. Baseline Orders Process for USMC Officers 


• Activity "A": This activity includes producing 

and maintaining the T/O's, running the PMR tool 
to generate the PMR, and determining a staffing 
priority each command (e.g., V-unit, priority, 
etc); essentially, all the high level activities. 

• Activity "B": This is where the "rubber meets 

the road." Monitors set about determine who will 
be moving and when, what billets are or will need 
to be filled, apply the various criteria outlined 
by both MCO P1300.8G and the Officer's 

Development Handbook, propose assignments, and 
get approval for these proposals. If the 

proposal is not approved, the monitor set about 
modifying the proposal to satisfy the 
requirements articulated by his or her 

supervisor. 

• Activity "C": This is where the mover discovers 

how well the process works. The monitor 

disseminates the orders. MCTFS is updated 

(either automatically or by hand depending on the 
method used to disseminate the orders). Once the 
mover receives his or her orders, if there is 
some problem with the assignment or 

detachment/reporting dates, the mover can 

communicate with his or her monitor to get the 
orders modified to better meet his or her needs. 
With the orders issued, mover in receipt of the 
orders, and MCTFS updated, the process can begin 
anew. 

Having completed an analysis of the baseline process, 
the metrics contained in Figure 4-1 were inputted to KOPeR- 
lite. The recommendations generated by KOPeR-lite are 
contained in Appendix C. Explanations of KOPeR-lite's 
Redesign Recommendations are contained in Appendix D. 
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Using these recommendations as a point of departure, two 
redesign alternatives are provided below. 

B. PROPOSED REDESIGN ALTERNATIVES 

As it indicated in Appendix C, KOPeR-lite identifies 
three areas that exhibit process pathologies. These are 
parallelism, process friction (due to a high activity to 
handoff ratio), and the process friction generated by 
excessive feedback loops (checking and complexity in KOPeR- 
lite terms). 

With regard to parallelism, each activity is dependent 
on the output of the activity preceding it. Therefore, no 
recommendations are provided for process delinearization. 
The focus of the redesigns proposed below, therefore, will 
be on reducing process friction and increasing IT 
automation. 

The focus of the first redesign is to propose changes 
requiring minimal capital outlays, but still yield positive 
results. A more "radical redesign" is proposed in the 
second alternative. The costs of implementing some of the 
recommendations could prove prohibitive, but the resulting 
impact will be far greater than what could be achieved by 
implementing the recommendations made in the first 
alternative. 

1. Redesign Alternative #1 

One of major areas of dissatisfaction from the mover's 
standpoint is the small amount of influence he or she has 
over their next assignment. This is due, in part, to the 
amount of information made available to the mover with 
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regard to current and projected billet vacancies. To solve 
this problem, one recommendation would be that information 
about current and projected billet vacancies used by the 
monitors be made available to movers. This information 
could be made available by posting it to a website. Movers 
would continue to communicate their desires using the same 
communication channels present in the baseline process. 

Empowering monitors to issue orders without explicit 
supervisory approval could reduce process friction. 
Proposed orders could be issued to supervisors where they 
would be given a certain amount of time to review them. 
During this review period, supervisors would have the 
opportunity to request a modification to the proposal. 
Once the review period elapses, the monitor would be 
allowed to disseminate the orders without further adieu. 

Other problems relate to the order issuance activity. 
These stem from the numerous methods used to disseminate 
PCS orders to officers. Since only one method, AWOPS, 
automatically updates the information contained in MCTFS, 
it is recommended that orders only be issued using this 
method. This will result in MCTFS containing more 
accurate, timely information, which will ultimately provide 
planners with better information to use during the planning 
phase of the orders process. 

The figure below outlines the changes proposed above: 
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Figure 4-2. Alternative #1 Modified PCS Orders 


Process 


2. Redesign Alternative #2 

As was recommended in the first alternative, movers 
should be given access to information about current and 
projected billet vacancies. This could be accomplished by 
making this information available on a website. Movers 
could then input their billet preferences in an online 
form. A message would be automatically sent to the 
appropriate monitors who could then use this information to 
assign the officer to a billet that most closely matches 
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the mover's professional and personal needs/desires. This 
should result in greater satisfaction on the part of the 
mover once he or she receives orders and should eliminate 
the feedback loop between the "orders issuance" and 
"mapping of mover to billet" activities in all but 
exceptional cases. 

In terms of IT automation, a system could be developed 
whereby orders are automatically issued once the supervisor 
approves the PCS order proposals submitted by monitors. 
For instance, the proposal could be forwarded to the 
supervisor using a groupware application like LotusNotes. 
Once approved, a middleware application could then transfer 
the information contained in LotusNote to AWOPS so that 
orders can be generated and MCTFS updated. This would be a 
significant improvement over the baseline process since one 
feedback loop would be eliminated and a manual orders 
generation process would be eliminated. This would both 
decrease process friction and increase process efficiency. 

An alternative method for decreasing the friction 
present would be to empower the monitors. The first 
alternative still involves submitting proposed orders to 
supervisors for review. Perhaps a study should be 
conducted to determine if this review activity offers any 
added value. If there is no value added, the review 
activity should be eliminated. This would decrease process 
friction both in terms of handoffs and feedback loops. 

Additionally, a single means of orders dissemination 
should be used. Instead of receiving orders in any of the 
six methods used in the baseline process, one standard 
method should be adopted, such as the AWOP system. The key 
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point here being that the method used should generate 
automatic system updates so that the information contained 
in MCTFS is accurate (which will result in a more accurate 
PMR) . 
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Figure 4-3. Alternative #2 Modified PCS Orders Process 
Note the elimination of the supervisory review activity 
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V. 


SUMMARY, CONCLUSIONS, AND FUTURE RESEARCH 


A. SUMMARY 

This thesis showed, through a process of statistical 
analysis and qualitative assessment, the viability of using 
automated tools, such as KOPeR-lite, when undertaking 
process reengineering projects. Additionally, 
reengineering solutions for the permanent change of station 
orders process for USMC officers were developed using a 
combination of the recommendations generated by KOPeR-lite 
and personal insight. These redesigns will be made 
available to the leadership in the Headquarter, U.S. Marine 
Corps (HQMC) Manpower and Reserve Affairs (M&RA) branch for 
review and possible adaptation as this branch moves to 
implement the Defense Integrated Military Human Resource 
System (DIMHRS). One of the proposed solutions may 
dramatically improve process performance. 

Chapter I establishes the need for research and 
outlines the questions to be answered. Chapter II provides 
a brief historical outline of process reengineering and why 
it is pursued. Additionally, the Davenport framework is 
presented along with a functional description of KOPeR- 
lite. KOPeR-lite is used to depict processes and gain an 
understanding for redesign. Chapter III covers the 
experimental design, data, analysis, results and 
implications. Chapter IV addresses the matter of 
reengineering the permanent change of station (PCS) orders 
process for USMC officers. It provides a description of 
the fundamental baseline process, recommendations generated 
by KOPeR-lite for process redesign, as well as proposed 
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process redesigns developed using the KOPeR-lite's 
recommendations as a point of departure. Chapter V 
provides conclusions, recommendations and topics for 
further research, which are presented below. 

B. CONCLUSIONS 

Redesigns generated by BPR novices who use KOPeR-lite 
to aide them in their reengineering efforts are superior in 
terms of process enablers (IT and non-IT), reduced process 
friction through a reduction in handoffs, and redesign 
clarity to those produced by novices working alone. This 
statement is supported by the analysis discussed in Chapter 

III. 

In light of the benefit KOPeR-lite provides, a new 
process was selected for modification; the permanent change 
of station orders process for USMC officers. This process 
was analyzed in much the same way as the process contained 
in Appendix A. The metrics were inputted into KOPeR-lite 
and the resulting redesign recommendations were used as a 
point of departure for the redesigns proposed in Chapter 

IV. Subsequent analysis of these redesigns using KOPeR- 
lite show that each of the proposed alternatives solve some 
of the pathologies associated with the baseline process. 
Each of the alternatives has been analyzed by KOPeR-lite 
and the results it its analysis are contained in Appendix 

C. 

C. RECOMMENDATIONS 

Individuals who are tasked with reengineering business 
process who have little or no experience in the field of 
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BPR, should consider using KOPeR-lite or a similar tool to 
assist them. The recommendations such tools generate 
provide an excellent foundation on which they can develop 
process redesigns. 

Additionally, HQMC, M&RA should take steps to modify 
the current processes followed for managing the officer 
corps in general and the PCS orders process specifically. 
The ideas that compose the alternatives proposed in Chapter 
IV should be considered for incorporation when this process 
is redesigned. 


D. FUTURE RESEARCH 

KOPeR-lite in its current form, is only designed to 
assist in reengineering knowledge-based processes. 
Therefore, one area which warrants additional is to expand 
the rule set employed by KOPeR-lite so that it can provide 
redesign recommendations for process belonging to other 
domains. 

A more rigorous statistical analysis should be 
conducted on the data collected from this initial 
experiment. 

Additional experiments should be conducted which build 
upon the one analyzed in Chapter III. Follow-on 
experiments should focus on expanding the pool of 
experimental subjects. Included in this pool of 
experimental subjects should be working professionals 
outside the military. Subjects should also represent a 
broader range of educational backgrounds. By expanding the 
pool of subjects, the results of subsequent statistical 
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analyses can be more easily generalized to the population 
at large. 
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APPENDIX A. DR. MARK'S SOFTWARE DEVELOPMENT CASE 19 


This minicase centers around a generic software 
development process, the baseline of which is described 
below. First a narrative description of the case is 
provided. This is followed by a high-level process model 
used to obtain measurements. The measurements can be used 
in turn for KOPeR analysis. 


A. BASELINE PROCESS 

A major service provider has a separate organizational 
unit that is responsible for the development of large 
software applications. Software development represents a 
key sub process in support of both front- and back-office 
operations, as the ability to seamlessly integrate 

marketing and sales with order fulfillment and product 
support represents a strong selling point for the company. 
However, customer feedback has suggested that the process 
has a number of shortcomings and flaws, particularly with 
respect to the long cycle time required to prepare a 

software application and the inability to report on the 
status of a particular package while it is being processed. 
A closer examination of the process flow activities should 
help elucidate some of these shortcomings and flaws. 

The process involves three Value Stream participants: 

This mini case was written by Professor Mark Nissen 
(http://web.nps.navy.mil/~menissen), initially for his Electronic 
Commerce course at UC Berkeley, and is now used in a number of graduate 
courses at the Naval Postgraduate School. It represents an 

amalgamation of many software development processes, as opposed to any 
one particular case, with the express purpose of promoting class 
discussion about process redesign. This mini case may be used for 
instructional purposes without fee, but must be cited in any academic 
works. 


59 





1) Field Sales groups with representatives that work 
to identify new customer requirements, 

2) the software development organization, and 

3) a third party software validation company. 

The software development organization is organized in 
terms of four functional departments, each of which is 
staffed with specialists for the functional areas: 

1) requirements, 

2) design, 

3) coding, and 

4) test. 

A process representation is presented below. 



Test 


From the figure you can observe that the process flow 
is sequential, beginning with a telephone call from the 
field sales representative to the requirements manager in 
the software unit. This functional manager writes the 
customer-requirements information on a piece of paper and 
assigns the job to a requirements specialist from the 
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department. This assignment is accomplished simply by 
placing the paper in the specialist's in-box. The 
requirements specialist retrieves the paper from his or her 
in-box, and begins to integrate the requirements of the 
potential customer into the functionality of the firm's 
existing software. This integration is accomplished 
manually, but the agent creates a requirements document 
using a word processing application on a standalone 
computer terminal in the specialist's office. 

Once the requirements specialist completes the 
requirements document, he or she reviews the results with 
the department manager. Upon approval, the paperwork is 
then mailed to the Design Department, where another 
functional manager will assign a design specialist to work 
on the job. The design specialist in turn will retrieve 
the requirements document from an in-box and design the 
software using a CASE tool on a standalone workstation in 
the specialist's office. Once developed, the logical 
design is reviewed with the design manager. Upon approval, 
the design documentation is printed and mailed to the 
Coding Department, where another functional manager 
similarly assigns the job to a coding specialist and places 
the paperwork in the appropriate in-box. 

The coding specialist is responsible for implementing 
the software through programming code. A rapid application 
development (RAD) tool suite is used to develop the 
software code, which tool suite resides on a desktop 
workstation in the specialist's office. The code is 
compiled and debugged, copied to disk and mailed to the 
Test Department. As in the departments above, a functional 
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manager in Test assigns a test specialist to execute the 
software code under a number of various test scenarios. 
When complete, the test results are reviewed by the 
functional manager and then sent along with the software 
code to an independent verification and validation (IV&V) 
firm, generally via overnight air service. Once received, 
the IV&V representatives verify the results of each step in 
the software development process and validate the end 
product satisfies the original requirements outlined by the 
field sales agent. The IV&V results are in turn forwarded 
to Field Sales, provided the software checks-out OK. 

It important to note, at each stage of the process, 
some manner of quality assurance is performed, and work 
products (e.g., requirements documents, software designs, 
compiled code) not up to standards are returned to the 
originating department for rework. In the case of the IV&V 
step, work can be returned back to any of the four 
functional departments associated with the software 
development. The cycle time for this process is generally 
between one and two months for a relatively straightforward 
software implementation. 

B. PROCESS MODEL 

The baseline software development process can also be 
represented in terms of a graphical model such as the one 
below. It includes the key process activities, attributes 
and measurements. Specifically, the six primary activities 
from above are included as nodes in this graph-based 
representation--!) Sales needs identification, 2) 
requirements development, 3) software design, 4) coding, 5) 
test, and 6) IV&V. Each activity node is linked to its 
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predecessor (s) and successor (s) through directed edges and 
is defined in terms of four attributes shown. 



"0" designates the performing organization in the 
process (e.g.. Sales Department, Requirements 
Department) 

"A" designates the agent role in the process 
(e.g.. Sales Agent, Requirements Agent) 

"S" designates the information technology 
employed for support in the process (e.g., word 
processor (WP), computer-aided software 
engineering (CASE) tool) 

"C" designates the media/technology employed for 
communication in the process (e.g., phone, 
report) 


Graph-based counting rules are used to obtain 
measurements for the process. For instance, process size 
(6) represents the number of activity nodes in the process 
and process length (6) is measured as the longest path 
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through the process. Notice the two feedback loops in the 
diagram (e.g., from test back to coding and from IV&V back 
to design. They are counted (2) as are the five handoffs 
of work from agents performing in different roles (e.g., 
from the Sales Agent to the Requirements Agent) . The WP, 
CASE, RAD and simulation (sim) tools are counted in the IT- 
support total (5) , but phone- and paper-based 
communications do not contribute toward the IT- 
communication count. These measurements should suffice to 
provide KOPeR input for measurement-driven inference. 
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APPENDIX B. EXPERIMENTAL CASE DATA 


A table of explanations for assignment of quantitative 
assessments of the students' proposed redesigns are 
provided in the following pages. 

For each redesign, three passes are made to evaluate 
the criteria laid out in chapter III par A. The first 
pass was made by the author and is annotated in BLACK. 
The second pass was made by Professor Nissen and is 
annotated in RED. The third and final pass represents and 
integration of the two analysts' finding and is annotated 
in BLUE. The results of this third pass are what was used 
to populate the spreadsheet contained in par 2 below. 

A. WITHOUT KOPER—LITE 




Quality 


Subject # 

Redesig 

n# 

Delinear¬ 

ization 

enablers 

non-value 
added items 
removed 



Clarity 

Impact 

Subject #1 

1 

Y: Combined 
req and design 

0 

0 

0 

-1: With 
creation of 
Req/design 
team, one 
handoff is 
eliminated 

3 

1: Design/Req 
combo w/o IT 
enablers will 
probably result in 
minimal 
improvements 


■ 

N: still 
sequential 

same PLUS 
OD: job 
enlargement 

same 

same 

same 

same 

same 



N 

OD: job 
enhancement 

0 

0 


3 

i 


2 

N 

4: email, 
workflow s/w 
(i.e. Lotus 
Notes), CASE 
tools, 
computer 
network 

0 

0 

0 

3 

2: IT enabled 
comm. Between 
activities will 
produce 
noticeable 
improvements; 
however, IT alone 
will not result in 
optimal results 



same 

same 

same 

same 

same 

same 

same 



N 

4: email, 
workflow s/w 
(i.e. Lotus 
Notes), CASE 
tools, 
computer 
network 

0 

0 

0 

3 

2 
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4 

0 

0 

•1 

3 

3: IT enablers 
combine with OD 
changes and 
reduced feedback 
loops will result in 
significant 
improvements 

same PLUS 

OD 

same 

same 

same 

same 

same 


0 

0 


3 

3 

2: Network, 
email 

0 

0 

0 

2 

1: Simply 
providing for 
paperless 
communication is 
not enough to 
realize significant 
improvements 

Same 

Same 

Same 

Same 

1: no 
diagram 

same 

2: Network, 
email 

0 

0 

0 

1 

i 

4: Email, 
conference 
call, FTP, 
network 

0 

0 

0 

same 

2 

1: Additional IT 
enablers have 
been introduced, 
but there is still no 
mention of how to 
change work 
processes to fully 
realize the 
benefits the IT 
enablers could 
afford 

Same 

nbox 

Same 

Same 

1: no 

separation or 
redesigns 

same 

4: Email, 
conference 
call, FTP, 
network 

0 

0 

0 

1 

i 

4: email, ftp, 

network, 

internet 

0 

0 

0 

2 

1: introduction of 

IT enablers is not 
sufficient to bring 
about significant 
improvement 

Same 

same 

same 

same 

1: no 
diagram 

same 

4: email, ftp, 

network, 

internet 

0 

0 

0 

1 

i 

4: Conference 
call, email, ftp, 
network 

0 

0 

0 

2 

1: introduction of 

IT enablers and 
automating "as is" 
processes are not 
sufficient to bring 
about significant 
improvement. 
Processes should 
be changed to 
take advantage of 
the full potential of 
IT enablers 


1: no 

separation of 
[redesigns 


same 


Inbox 


same 


;ame 


same 
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IS 


;ame 


same 


same 


3:IT; 1 non IT 0 


Subject #8 


Y: combine 
Req/Design and 
Code/Test 

0 

N: no mention of IT: email 
delin IT: network 

No statement 
that trans or 
cumulative 

N 

2 IT; 0 non-IT 

N 

2: email, FTP 

same 

same 

N 

2 IT; 0 non IT 

Y: Req/Design 

3; email, 


activities 

combined 


internet, FTP 


1: addition of 
customer 
feedback loop 


1: Merging 
activities with no 
introduction of IT 
or non-IT 
enablers will 
produce little 
more than a 
cosmetic change 


same 


same: 
diagram, 
separation, 
but unclear 


3: Integration of IT 
and non-IT 
enablers, change 
in processes, and 
elimination of 
physical 
separation of 
activities together 
promise to 
increase 
information 
exchange,reduce 
friction, and 
facilitate more 
rapid S/W 
development 
efforts 


ame 


Y: Req/Design 

activities 

combined 


3 IT;2 non IT 


■; email, 0 
internet, FTP, 
organizational 
Knowledge- 
Based system 


9: This 0: (same as 
increase is due above) 
to the 

incorporation 
of an 

automated 
knowledge 
base into 
which each 
activity is 
linked 


2: Though the KB 
may eventually 
prove as effective, 
I believe there is a 
lot to be said for 
face to face 
interaction in a 
"creative" 
endeavor like S/W 
development 


same: 

diagram, 

separation 
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Subject #9 



2: distributed 

database, 

network 

0 

same PLUS 

IT: CASE 

same 

2 IT 

0 



OD: combine 4 same 
depts 


0 IT;1 non IT 


1: email 0 




Same 


1 IT; 0 non IT 


N: however, she 8: email, 
proposes using database, 
a case manager LAN, workflow 
to reduce friction S/W, DSS for luse of Visible 
between employee 
activities and selection, 
maintain project internet, RAD 
status to capture reqs 

awareness and generate 
S/W prototype, 

Lotus Notes 



2: elimination II: addition of 
customer 
feedback loop 


enerate code 
utomatically, 


-2: from 5 to 3 
w/ elimination 
of Code and 
IV&V activities 


1: simply 
automating a 
single step 
without looks for 
other ways to 
benefit from IT 
enablers limits 
impact 


same 


3: Though I 
believe some of 
her assumptions 
to be flawed (i.e. 
Coding can be 
entirely through 
automation), her 
extensive use of 
IT and non IT 
enablers, case 
manager, and 
process changes 
to capitalize on 
benefits afforded 
by IT enablers 
promise 
significant 
improvement 


ame 



Subject #111 Y: combine 2: centralized 0 
Code/Test database, 
activities; Test email 
and IV&V done 
simultaneously; 
use of case mgr 


2: from 5 to 7 - -1: from 5 to 4 2 

feedback with integration 

between all of Code/Test 

activities and 

case manager 

will be 

required. 


combining 
Design/Code 
activities into an 
integrated team 
and havin 
gTest/IV&V done 
simultaneously in 
conjunction with 
the use of a case 
manager coupled 
with IT enablers 
such as email and 
shared databases 
promise 
significant 
improvements 
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same 

Same PLUS 3: 
??? 

same 

same 

same 

same 

same 



y 

2 IT;3 non iT 

0 

2 

■i 

2 

2 


2 

Y: combine 
sales/reqs, 
Code/Test, and 
Test and IV&V 
done 

simultaneously 

2: centralized 

database, 

email 

0 

1: from 5 to 6 - 
feedback 
between all 
activities and 
case manager 
will be 
required. 

■2: from 5 to 3 
with integration 
of Code/Test 
and Sales/Req 

2 

3: a further 
enhancement of 
his first redesign 
which results in 
less friction and 
additional job 
enrichment 



same 

Same PLUS 3: 
??? 

same 

same 

same 

same 

same 



y 

2 IT; 3 non IT 

0 

i 

■2 

2 

3 

Subject #12 

1 

N 

3: LAN, 

database, 

email 

0 

Unable to 
determine from 
analysis 

Unable to 
determine from 
analysis 

1 

1: Use of IT 
enablers alone 
will not produce 
the process 
improvements 
sought 



same 

same 

same 

0 

0 

same 

same 



n 

3 

0 

0 

0 

0 

i 


2 

Y: Combine 
Req/Design 
activities and 
Code/Test 
actiivities 

2: LAN, VTC 

0 

Unable to 
determine from 
analysis 

Unable to 
determine from 
analysis 

1 

1: minimal use of 
IT enablers and 
lack of process 
change beyond 
just combining 
activities, limits 
the impact of this 
redesign 



same 

Same PLUS 
??? 

same 

■1 

■1 

same 

same 



No 

2 IT;1 non IT 

0 

■1 

■1 

i 

i 

Subject #13 

1 

Y: states 
"combine 
requirements 
and design" and 
then depicts 
Sales using a 
CASE to 
develop the 
Reqs, so it 
appears as 
though he's 
actually 
combined 
Sales/Req/Desi 

gn 

4: CASE and 
WP for Sales, 
email, S/Wto 
convert CASE 
developed Req 
Doc into a 
design and 
coding doc 

0 

0: he depicts a 
reduction from 

2 to 1, but he 
eliminates the 
feedback loop 
between IV&V 
and design 
which doesn’t' 
make sense as 
without this 
feedback loop, 
the "final rpt" 
IV&Vdeveiops 
would not be 
returned to the 
S/W dev 
company 

■2: from 5-3 
with 

combination of 
Sales/Req/Des 
ign activities 

2 

2: Use of IT 
enablers along 
with work flow 
redesign (i.e 
integrating 
Req/Design) 
promises 
moderate 
improvements 



N: still 
sequential 

same PLUS 
OD: combine 
depts 

same 

same 

same 

same: 

diagram, sep 
of redeisngs, 
but unclear 

same 



N 

4 IT;1 non IT 

0 

0 

■2 

2 

2 
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Subject #21 


N 

3: personal 
computers, 
email, network 

0 

3: from 2 to 5 
with creation of 
case mgr and 
feedback to 
the CM by 
each activity 
internal to the 
S/W 

Development 

division 

0: handoffs 
•emain the 

same. 

Though he 
depicts an 
additional 
nandoff 
oetween sales 
and the CM in 
lis graphic 
•epresentation, 
n my textual 
description of 
nis redesign, 
ie states that 
the CM tracks 
and the 
divisions hand 
off to one 
another 

2 

1: Moderate use 
of IT enablers but 
excessive 
reliance on case 
worker increases 
friction and 1 
believe may 
actually result in 
development 
slowing 




same PLUS 
OD: 

empowerment 

0-4 mgrs 

0 


3: diagram, 
separation 

same 



N 

3 IT; 1 noN IT 

4 

0 

•3 

2 

i 


2 

Y: creation of 
development 
teams 

(Req/Design/Co 

de/Test) 

3: personal 
computers, 
email, network 

0 

0: remains at 2 

■2: from 5 to 3 

2 

2: Moderate use 
of IT enablers and 
development of 
Design Teams 
promises 
increased 
interaction 
between activities 
thereby reducing 
friction 


■ 

N: still 
sequential 

same PLUS 
OD: design 
team 

4: mgrs 



3: diagram, 
separation 

same 



N 

3 IT;1 non IT 

4 

-3 

■6 

3 

2 


77 




































B 


WITH KOPER—LITE 


Subject # 

Redesign 

# 

Delinearization 

enablers 


change in # of 

feedback loops 

change in # of 

hand-offs 


Impact 



N 

4: DBMS, email, 
LAN, WAN 

0 

-1: elimination of 

feedback 
between internal 
Test and Code 
activities 

0: remains 
unchanged from 
baseline process 

3 

1: minimal use of 

IT enablers, no 
org change 



same 

same PLUS 

OD: 1 mgr 

OD: 

empowerment 

manger review? 

same 

same 

same 

same 



N 


0 

-i 

0 

3 

i 


2 

N 

LAN, case 
manager 

0 

0: unchanged 
(not addressed in 
redesign) 

0: unchanged 
(not addressed in 
redesign) 

1: diagram does 

not depict case 
manager 
nvolvement or 
feedback loops. 
Metrics are not 
orovided for the 
second redesign 

1: minimal use of 
IT enablers; case 
manager 
inserted, but roll 
not described; 
process changes 
not discussed 



same 

Same 

1 

same 

same 

same 

same 



n 

1 

1 

0 

0 

0 

i 

Subject 

#23 

1 

Y: use of 
Design/Code/T 
est teams, use 
of Case 
Manager 

8: email, EDI via 
online customer 
request form, 
shared database, 
experty system 
for requirements 
integration, 
network, LAN, 
VPN, use of 
internet 

0 

-1: from 2 to 1 
with the 
elimination of 
feedback 
between Code 
and Test 
activities in light 
of the new 
"team" concept 

-2: from 5 to 3 

2 

3: extensive use 
of IT enabler, 
organizational 
design altered 
and discussion of 
work process 
changes 
highlighted, 
inclusion of case 
manager and 
development 
team concept 




same 

manger review? 

same 

same 

2: diagram, 
unclear 

same 



N 

8 IT: 0 non -IT 

0 

-i 

-2 

2 

3 


1 

Y: integrated 
req/design/cod 
e/test team 

4: LAN, shared 
files, email, 
automated 
requirements 
generation tool 

0 

-4: from 5 to 1 
with creation of 
integrated 
development 
team 

-3: from 5 to 2 
with creation of 
integrated 
development 
team 

2 

3: significant use 
of IT and non-IT 
enablers, case 
mgr, devel team, 
steps to reduce 
friction, facilitate 
comms 




Same 

same 

same 

same 

1: hard to follow 

same 



N 


0 

-4 

-3 

2 

3 


78 








































































: case 0 
manager for all 
but IV&V 
activities 



Y:case 4: internet, 

manager for all intranet, shared 
but IV&V database, LAN 

activities plus 
creation of 
Req/Design/Co 
de team 



4: from 5 to 1 
with 

incorporation of 
case manager 




1: use of case 
manager will 
decrease friction 
but will not 
facilitate speed 
of 

communications 
in light of no IT 
enablers for 



4: from 5 to 1 
with 

incorporation of 
case manager 



2: use of IT 
enablers in 
conjunction with 
case manager 
concept, 
however, this 
redesign seems 
to imply business 
is done the same 
basic way even 
though some 
steps are now 
digitized. 




4: from 5 to 1 
with 

incorporation of 
case manager 




3: extensive use 
of IT and non-IT 
enablers, case 
manager, 
development 
teams, work flow 
redesign 
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6: server-based -7: elimination of 0: remain same 
network, FTP, "mail" process as baseline 

internet, accounts for 5 of 

webpage, email, these eliminated 
expert system processes 




6: server-based 
network, FTP, 
internet, email, 
expert system, 
code generator 


7 IT:0 non IT 


: combined 5: Group ware, 
Sales/Require workflow system, 
ments expert system, 

consolidated all and implied are 
the various internet/intranet 

processes 
performed by 
individual 
"organizations" 
into single 
activities. 



6 IT:0 non IT 


6: server-based -10: elimination 
network, FTP, of mail 
internet, processes plus 

webpage, email, automation of 
expert system code generation 
account for these 


-12: elimination 
of 13 processes 
and the addition 
of one new one., 
the "customer 
advocate." 
Requirements 
process is 
greatly 

streamlined and 
snail mailing of 
outputs to follow- 
on activities 
eliminated with 
incorporation of 
additional IT- 
automation 


-4: from 7 to 3; 
some feedback 
loops resulted 
from his analysis 
and breaking 
down activities 
into their 
component 
processes. 


-12: from 17 to 5; 
this results I 
large part do to 
his consolidation 
of all the various 
processes 
performed by 
individual 
"organizations” 
into single 
activities. 


2: moderate use 
of IT enablers to 
decrease comm. 
Delays, no work 
flow or process 
changes to 
compliment IT 
enablers. 



3:: change in 
work processes, 
activity 

automation (i.e. 
code 

generation), 
further reduction 
in handoffs 




2: moderate use 
of It and non IT 
enablers (case 
manager) 
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same 



Y: 5: Group ware, -13: elimination 

Development workflow system, of 15 processes 
of expert system, and the addition 

Design/Code/T and implied are of two new 
est teams internet/intranet ones., the 

) "customer 

advocate" and 
"form new 
product team." 
Requirements 
process is 
greatly 

streamlined and 
snail mailing of 
outputs to follow- 
on activities 
eliminated with 
incorporation of 
additional IT- 
automation 


,: Group ware, 
expert system, 
and implied are 
internet/intranet 
OD: customer 
advocate 
OD: eliminate 
depts. (case 


-6: from 7 to 1; -13: from 17 to 4; 

however he again this results 

doesn't consider I large part do to 
the feedback that his consolidation 
must happen of all the various 

with the inclusion processes 
of a "customer performed by 
advocate" (aka individual 
case manager), "organizations" 



3: moderate use 
of IT enablers 
coupled with 
non-it enablers 
like customer 
advocates and 
development 
teams expected 
to yield 
significant 
improvements 



2: minimal use of 
IT enablers, 
good use of non- 
IT enablers such 
as case mgr and 
development 
teams 
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3: online form, 0 
internet, intranet 


-1:2 to 1 w/ 
creation of 
Development 
Team 


■2: from 5 to 3 w/ 
creation of 
development 
earn 



Same PLUS 

same 

same 

s 

ame 

al 

OD: combine 
des/code/test 







3 IT:1 non IT 


5: website, online -1: elimination of -1: from 2 to 1 w/ 
Design/Code form, internet, sales; customer loop going from 

combined as a intranet, email submits IV&V to Design 

single activity requirements via 

the web 



same 


5 IT:0 non IT 


Internet/intranet, 
electronic form, 
email, automated 
requirements 
document 
development tool 


same 


5 IT: 0 non IT 


Internet/intranet, 
electronic form, 
email, automated 
requirements 
document 
development tool 


Same PLUS 
OD: combine 
des/code/test 
OD: single mgr 


5 IT:2 non IT 



2: good use of IT 
comm. And IT 
support in Code 
activity. 
Elimination of 
Sales is not seen 
as an 

enhancement as 
many customers 
benefit from the 
give and take w/ 
a person when 
rying to clearly 
articulate their 
needs/reqs 


same 


2: moderate use 
of IT enablers 
but little change 
to underlying 
processes 



-1: from 2 to 1 w/ -2: from 5 to 3 
creation of with creation of 
integrated integrated 

Design/Code/TesDesign/Code/Tes 
t team t team 
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-2: from 5 to 3 

1: unclear which 

with creation of 

activities are 

single 

combined either 

Design/Code/Tes by reading or 

t activity 

referring to 

same 

redesign digraph 








N 0 IT:1 non IT 0 


: Combine 7: LAN/WAN, 
Design/Code/T email, shared 
est activities databases, 

electronic forms, 
electronic 
graphical 
representation, 
VTC, CAD 









7 IT: 1 non IT 0 





same PLUS 
automatic queue 
system_ 


6 IT: 0 non IT 0 



,: Computer 
network 
(implied), email, 
partial auto form 
population, auto 
form verification 


-1: sales 
eliminated 



same PLUS 
OD Remove 
Sales 


0: unchanged -2: from 5 to 3 1: unclear which 

from baseline with creation of activities are 

single combined either 

Design/Code/Tes by reading or 
t activity referring to 

redesign digraph 





0: unable to 
determine 



0: unable to 
determine 














1: good use of IT 
enablers, no 
non-IT enablers 
(case mgr, team 
concept, etc) and 
little discussion 
on changing 
underlying work 
processes. No 
delin 






1: good use of IT 
enablers, no 
non-IT enablers, 
elim of sales may 
limit ability to 
capture customer 
needs as a sales 
person can 
probably help 
capture customer 
needs more 
completely 


same 
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2: email, network 0 
esign/code/te (implied) 
tteam 



1: minimal use of 
IT enablers, use 
fo devel team 
concept, but no 
discussion on 
changing 
underlying 
processes or 
delinearizing 
activities 


req/design/cod (implied) 
e/test team 


same PLUS 
OD: case team 


2 IT: 1 non IT 0 


2: email, network 0: though unclearNot addressed L3: from 5 to 2 II: failure to 



if req is merely by redesign; with 

combine w/ the feedback fraction incorporation of feedback loops 
case team or of 0.167 is req/design/code/t|makes it 

eliminated yielded by est team 

KOPeR output, 
but unable to 
determine how 
this number 
could be reached 
based on what's 
depicted in his 
digraph 


1: minimal use of 
IT enablers, use 
fo devel team 
concept, but no 
discussion on 
changing 
underlying 
processes or 
delinearizing 
activities 


s simply 
eliminated 





same PLUS 
OD: case team 


2 IT:1 non IT 


2: email, network -1: elimination of -1: from 2 to 1 
IV&V with elimination 

of IV&V and its IV&V 
resultant 
feedback loop 


-1: from 5 to 4 w/ 
elimination of 



3: IT and non-IT 
enablers, case 
team, case 
manager concept 
all integrated 
with discussion 
on changing 
underlying 
processes (i.e 
requirements 
development 
process) 





same PLUS 
WF: eliminate 
IV&V 

OD: combine 
Sales/Req 
IT: Req DSS 
OD: PM 


3 IT:2 non IT 


2: email, network -1: elimination of -2: from 2 to 0 
IV&V 





: -2: from 2 to 0 -3: from 5 to 2 

with elimination with elimination 

of IV&V and of IV&V and 

creation of creation of 

Design/Code/Tes Design/Code/Tes 
t team where t team 

feedback would 
occur 

consequent to 
the iterative 
nature of the new 


imanager 



3: good use of IT 
and non IT 
enablers, case 
team, case 
manager, 
iterative 

development and 

incremental 

testing 
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APPENDIX C. KOPER PATHOLOGY DIAGNOSIS AND REDESIGN 
ADVICE; PCS ORDERS PROCESS FOR USMC OFFICERS 


A. BASELINE PROCESS 

1. Diagnosis 

Measurements (e.g., size of 5) suggest the small PCS 
orders Process for USMC Officers process suffers from the 
following pathologies: 

• Parallelism ( 1 . 0 ) - sequential process. 

• Handoffs fraction ( 0 . 8 ) - process friction. 

• Feedback fraction ( 0 . 6 ) - checking & complexity. 

• IT support fraction (2.2) - IT support looks OK. 

• IT communication fraction ( 0 . 6 ) - IT 

communication looks OK. 

• IT automation fraction ( 0 . 0 ) - inadequate IT 

automation. 

2 . Recommendations 

For redesign, we recommend you consider the following: 

• Delinearize process activities to increase 

parallelism; such activities must be 

sequentially-independent (e.g., have mutually- 

exclusive inputs and outputs). 

• Try a case manager or case team to decrease 

friction; be sure to include a source of 
expertise. 

• Try empowerment to reduce the amount of checking 
in the process; be sure to address training and 
incentives. 

• Look to information technology to automate 

process activities; automated transaction 
processing and expert systems generally have good 
payoffs and intelligent agents can enable many 
electronic commerce opportunities. 

• Try either asynchronous or contemporaneous 

reviews to conduct quality/feedback loops 
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concurrently or jointly; scheduling becomes a 
concern with this redesign. 

In addition to delinearization and the use of a 
case manager, workflow systems offer good 
potential for process improvement; try to avoid 
paving the cowpaths by ignoring other process 
pathologies, however. 


B. REDESIGN ALTERNATIVE #1 

1. Diagnosis 

Measurements (e.g., size of 5) suggest the small PCS Orders 
Process for USMC Officers suffers from the following 
pathologies: 

• Parallelism ( 1 . 0 ) - sequential process. 

• Handoffs fraction ( 0 . 8 ) - process friction. 

• Feedback fraction ( 0 . 2 ) - feedback looks OK. 

• IT support fraction ( 2 . 2 ) - IT support looks OK. 

• IT communication fraction ( 0 . 6 ) - IT 

communication looks OK. 

• IT automation fraction ( 0 . 2 ) - inadequate IT 

automation. 

2 . Recommendations 

For redesign, we recommend you consider the following: 

• Delinearize process activities to increase 

parallelism; such activities must be sequentially 
independent (e.g., have mutually-exclusive inputs 
and outputs) . 

• Try a case manager or case team to decrease 

friction; be sure to include a source of 
expertise. 

• Look to information technology to automate 

process activities; automated transaction 
processing and expert systems generally have good 
payoffs and intelligent agents can enable many 

electronic commerce opportunities. 

• In addition to delinearization and the use of a 

case manager, workflow systems offer good 
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potential for process improvement; try to avoid 
paving the cowpaths by ignoring other process 
pathologies, however. 


C. REDESIGN ALTERNATIVE #2 

1. Diagnosis 

• Measurements (e.g., size of 4) suggest the small 
PCS Orders Process for USMC Officers process 
suffers from the following pathologies: 

• Parallelism (1.0) - sequential process. 

• Handoffs fraction (0.75) - process friction. 

• Feedback fraction (0.25) - feedback looks OK. 

• IT support fraction (1.75) - IT support looks OK. 

• IT communication fraction (0.75) - IT 

communication looks OK. 

• IT automation fraction (0.75) - IT automation 

looks OK. 

2 . Recommendations 

For redesign, we recommend you consider the following: 

• Delinearize process activities to increase 

parallelism; such activities must be sequentially 
independent (e.g., have mutually-exclusive inputs 
and outputs). 

• Try a case manager or case team to decrease 

friction; be sure to include a source of 
expertise. 

• In addition to delinearization and the use of a 

case manager, workflow systems offer good 
potential for process improvement; try to avoid 
paving the cowpaths by ignoring other process 

pathologies, however. 
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APPENDIX D. EXPLANATIONS OF KOPER REDESIGN 

RECOMMENDATIONS 


A. DE—LINEARIZE 

De-linearization involves rearranging a sequence of 
process activities to be performed in a more parallel or 
concurrent manner. Process parallelism or concurrency has 
positive performance effects in terms of cycle time (and 
often cost), as activities are performed in parallel as 
opposed to sequentially. This redesign transformation 
affects the sequence and flow of process activities, but 
not how or by whom they are performed. 

B. CASE MANAGER 

The case manager transformation involves replacing 
specialized employees in a process (often from different 
functional departments) with a generalist case manager who 
performs all process activities from start to finish. A 
case manager can have positive performance effects in terms 
of cycle time (and often cost) , as a single case manager 
obviates the need for handoffs and inter-departmental 
coordination. A case team involves the same concept 
extended to a dedicated team of people. In the DoD, these 
are referred to as 'integrated product teams' (IPTs). 

C. EMPOWERMENT 

Empowerment involves delegating responsibility to 
front-line employees and authorizing the people doing 
process work to ensure the quality of their work. 
Empowerment can have positive performance effects in terms 
of cost and cycle time, as quality 'checking' steps can be 
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avoided and empowered employees often produce superior work 
products at lower cost. Empowerment entails some job 
enlargement. 

D. IT SUPPORT 

IT-Support involves the application of information 
technology (IT) to support process activities. This 
powerful redesign transformation can have positive 
performance effects in terms of cost and cycle time, as 
computer-based tools can augment human performance in terms 
of memory, speed, thoroughness and other attributes. As a 
'support' enabler, IT in this class is used in conjunction 
with human labor (i.e., in contrast to IT-Automation) . 


E. IT COMMUNICATION 


IT-Communication involves the 

information technology (IT) to 
communications. This powerful redesign 
have positive performance effects in 
cycle time, as computer-based tools can 
based communications. 


application of 
support process 
transformation can 
terms of cost and 
replace slow paper- 


F. IT AUTOMATION 

IT-Automation involves the application of information 
technology (IT) to automate process activities. This 
powerful redesign transformation can have positive 
performance effects in terms of cost and cycle time, as 
computer-based tools can replace and improve human 
performance. As a 'automation' enabler, IT in this class is 
used to obviate human labor (i.e., in contrast to IT- 
support). 
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G. JOINT REVIEWS 

The joint reviews transformation serves to eliminate 
the pathologies associated with a sequence of 
quality/feedback loops in a process. This can have positive 
performance effects in terms of cycle time, as reviews are 
handled once by all interested parties. However, this 
approach can actually increase cost if reviews are not 
managed effectively. Scheduling also becomes a concern. 

H. SEQUENTIAL INDEPENDENCE 

Delinearization can significantly reduce process cycle 
time, particularly when high-level process activities are 
delinearized. But if two process activities are 
sequentially dependent, they cannot be performed 
concurrently; rather, they must continue to be performed in 
series. 

One test for sequential-independence is to analyze the 
inputs to, and outputs from, each process activity. Where 
the inputs to an activity (call it Step-2) are not produced 
by the preceding activity (call it Step-1), the two 
activities offer good opportunity to be performed in 
parallel. 


I. EXPERTISE 

When a case manager or case team is instituted, the 
personnel performing in such process roles are usually 
generalists--broadly skilled in at number of different 
jobs--who are seldom endowed with expertise across all 
required tasks and activities. 
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The generalist worker (s) can be expected to perform 
well, so long as the process activities are not unusual, 
complex or novel. Performance of work that is not 
customary, simple and familiar often requires deeper 
expertise than is possessed by a generalist case manager. 
Thus, expertise is required to support the generalist in 
these situations. 

Expertise is most commonly provided through retention 
of some expert personnel, who can serve as advisors or 
internal consultants when problems arise. With the advance 
of knowledge systems technology, however, much of this 
expertise can be captured and formalized through 
intelligent systems. Expert systems for problem diagnosis, 
neural networks for pattern recognition, case-based 
reasoning systems for help desks, intelligent agents for 
information filtering, and other intelligent applications 
represent potential, alternative sources of expertise. 

J. TRAINING AND INCENTIVES 

Empowerment can create a number of process 
improvements by authorizing decisions to be made personnel 
who are directly responsible for performing process work. 
This can eliminate lengthy decision-making and feedback 
loops, and can augment process quality. 

However, employees who are unaccustomed to making 
decisions are likely to require training, in addition to 
having the requisite decision-making information provided. 
This represents a critical factor to the success of 
empowerment. 


96 



Personnel who are newly empowered are also likely to 
perceive a (real) increase in their level of 
responsibility. This represents a key motivating factor 
behind the increased process quality noted above, but the 
personnel must also be incentivized to take-on this 
additional (perceived) responsibility. Monetary 
compensation is not necessarily required, as employer- 
sponsored training, expanded job title, business cards, 
improved office surroundings and other factors can also 
incentivize many people. 

K. IT TRAINING AND MAINTENANCE 

Information technology represents a very powerful 
enabler of process innovation. IT to support process 
activities and communications requires personnel training 
in many organizations, however. Indeed, many techno-phobic 
employees will find new IT threatening, and are likely to 
resist change. Training represents one approach to 
addressing such employees. 

Techno-phobic or not, simply inserting new IT into a 
(human) process cannot be expected to produce dramatic 
process improvements unless the personnel are adequately 
trained to use the IT. Although this appears evident, many 
good redesigns have failed for lack of training. 

Additionally, IT needs to be maintained. Computer 
hardware requires repair and upgrading. New releases of 
software require installation. Databases and networks 
require administration. Indeed, software maintenance, for 
example, is known to consume roughly two-thirds of the 
total life cycle cost for software. 
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L. AUTOMATION AND ELECTRONIC COMMERCE 

Automation implies that IT is being employed to 
perform process activities instead of people, and 
represents a different class of redesign transformation 
than either IT support or communication. Yet an 
infrastructure of IT for support and communication is 
generally necessary for effective automation. 

Automated transaction process systems are well known 
for this effect and expert systems are increasingly being 
used to automate some aspects of knowledge work. With the 
advent of intelligent-agent technology, automation is 
reaching beyond routine transactions and self-contained 
expertise, and extending across network linkages to 
automate coordination and collaboration work as well. 

Much coordination and collaboration work is now 
accomplished between organizations and intelligent agents 
are playing an increasingly important role in this area. 
For example, using former EDI connectivity links, 
customers, channels and suppliers are finding an enhanced 
ability to locate, interact and conduct business with one 
another, without human intervention. 

M. IT INFRASTRUCTURE 

An IT infrastructure is particularly important to 
support the automation of knowledge and information work, 
and is generally considered to represent a necessary 
precondition for success. IT to support process activities 
(e.g., computers, software, decision support systems, 
databases, word processors, etc.) and communications (esp. 
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e-mail. Intranets, workflow systems) represent key 
infrastructural elements. 

A workflow system is often required to support many 
approaches to knowledge-work automation, particularly where 
work crosses agent roles and organizational boundaries. 
Intelligent agents require knowledge and information in 
digital form, so these, basic IT infrastructural elements 
are required even to begin such automation work. 


N. SCHEDULING 

Asynchronous reviews are less prone to scheduling 
concerns than their contemporaneous (i.e., joint) 
counterparts. When busy people must interact jointly, 
finding mutually-acceptable slack times in their schedules 
becomes exponentially more difficult as the number of 
required participants increases. 

Setting aside fixed times during the day, week, or 
month to address such reviews represents one approach to 
addressing scheduling concerns, and minimizing the number 
of required attendees is another proven heuristic. Also 
ensuring that all issues that can be resolved before such 
meetings can be crucial. 

O. WORKFLOW 

Workflow systems can support process activities 
through shared databases and networked communications, in 
addition to automatically routing work to the right 
agent(s) at the right time. This can save both process time 
and money. However, see the caution above regarding IT 
training and maintenance. 
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Most extant workflow applications are relatively 
rigid, in that once a process is defined, it cannot be 
changed dynamically (e.g., in response to in-process 
circumstances). Also, unless the underlying process work 
itself is changed, a workflow system can simply "pave the 
cowpaths" and speed-up the current "broken" process. 
Indeed, with new interfaces and without personnel training, 
workflow systems can even increase process cycle time, 
despite electronic communications that occur at speeds near 
that of light. 

The key is to redesign the underlying process work 
first, then ensure an adequate IT infrastructure, then look 
into workflow automation. As a note, workflow systems 
provide a wonderful infrastructural foundation for 
intelligent-agent applications. 
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